Re: [PATCH] 2/5: Device-mapper: kcopyd

[Kevin Corry <kevcorry@us.ibm.com>]

On Thursday 10 June 2004 6:18 am, Andrew Morton wrote:
> Alasdair G Kergon <agk@redhat.com> wrote:
> > kcopyd
> >
> > ...
> > +/* FIXME: this should scale with the number of pages */
> > +#define MIN_JOBS 512
>
> This pins at least 2MB of RAM up-front, even if devicemapper is not in use.

Is that really the case? The MIN_JOBS value is used to initialize the mempool 
of kcopyd_job structures (see kcopyd.c::jobs_init()). A kcopyd_job is 
(according to my calculations on i386) 272 bytes. If you assume they are 
nicely aligned, then we'll round that up to 512 bytes. This means you should 
be able to fit 8 of those structures in a page, and initializing to MIN_JOBS 
should only use 256kB of RAM. Granted, 256kB of RAM isn't all the great 
either, but it's about an order of magnitude less than 2MB.

Or am I not understanding how kmem_caches and mempools work?

The jobs_init() routine is run (and hence the kmem_cache and mempool are 
created) when kcopyd() is loaded, so the min-value has to be set to some 
static number. One possibility to cut down on the up-front memory usage would 
be to reduce the static MIN_JOBS value, and then use mempool_resize() when 
the kcopyd users call kcopyd_client_[create|destroy].

Another thing we could do would be to build kcopyd as its own kernel module. 
Right now it's built in the same module with the core DM driver, so it's 
loaded any time DM is loaded, regardless of whether any DM module is using 
it. It should be fairly easy to split it out in its own module, which means 
that mempool won't be created until some other module is loaded that depends 
on kcopyd.

-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/