Re: [lc-devel] Patch is up

[Rodrigo S. de C. <rc...@im...>]

On Mon, Oct 13, 2003 at 05:28:54PM -0400, John R Moser wrote:
> Yes there's some damage :P I've a few bad hacks, the alg can't be
> changed on the fly, and DON'T use compalg= for now (I'm not sure
> about how well that really works).

That's very simple. You declare "__setup" with the command-line option
and the function which will handle it. For example,

static int __init comp_cache_size(char *str)
{
       unsigned long nr_pages;
       char * endp;

       nr_pages = memparse(str, &endp) >> (PAGE_SHIFT +
       COMP_PAGE_ORDER);

       max_num_comp_pages = nr_pages;
       return 1;
}

__setup("compsize=", comp_cache_size);

In this case, "compsize=" kernel option is setup, and
comp_cache_size() will handle it. The option passed in the
command-line is the parameter to the function.

> I'm running WKdm and there's absolutely no problems.  WKdm is my
> default alg, compiled in, and I'm limited to 128MB RAM via mem=.
> Using 16x pages.
> 
> compressed cache - statistics
>  general
>  - (S) swap cache support enabled
>  - (P) page cache support enabled
>  - compressed swap support enabled
>  - maximum used size:   10112 KiB
>  - comp page size:         64 KiB
>  - failed allocations:    298
>  algorithm WKdm
>  - (C) compressed pages:      19895  (S:  83% P:  16%)
>  - (D) decompressed pages:     6592  (S:  98% P:   1%) D/C:  33%
>  - (R) read pages:             1711  (S:  91% P:   8%) R/C:   8%
>  - (W) written pages:          9276  (S: 100% P:   0%) W/C:  46%
>    compression ratio:            52% (S:  50% P:  62%)
> 
> 
> I'm working on the patch more now, kind of hacking the algorithm
> inits out of proc.c and proc.h.  I'll upload another patch in a few
> days probably, with the registration system in there.  It's going to
> be a simple registration system.  Probably the linked list will be
> as follows:

I guess you will probably keep working on the compression algorithms,
and making them modules. That's great, let me know of your progress.

> struct comp_cache_registered
> {
> 	short	algorithm_idx;
> 	char	*name;
> 	comp_cache_init_function_t	*init;
> 	struct comp_cache_registered	*next;
> }
> 
> on initialization I'll call ->init().  These will be referenced by
> their algorithm_idx, but the sysctl to list available algs will read
> their name.  Also, the default alg will be chosen by name.

I never worked with modules, your solution and implementation for this
registration idea is what most intrigues me now :-)

> I'm also working on making it SMP safe.  Bear in mind I have NO idea
> what this really involves but I'm making it safe to run these side
> by side.  At the same time.  With both CPUs on the exact same
> instruction.  Continuously.  I have class right now so bye.

Basically, that's all about the spinlocks. They protect kernel data
and function, and must be handled carefully, since they are crucial
for making use of the second CPU on a SMP system. Spinlocks don't make
sense when you are running a non-preemptive kernel on an UP system,
since kernel code isn't never forced to relinquish CPU, except for the
most urgent interruption handling. 

I implemented a basic spinlock system in order to be stable in a
kernel with preempt patch, however the concurrency level (which is
sort of "induced") isn't so high as on a SMP system. That's why you
have to test it on a SMP system and start noticing data corruption and
all sort of damages to your system :-), trying then to check where we
have unprotected data or race conditions.

Regards,
-- 
Rodrigo