Re: scsi command slab allocation under memory pressure

[Andrew Morton <akpm@digeo.com>]

James Bottomley <James.Bottomley@steeleye.com> wrote:
>
> On Fri, 2003-01-31 at 01:57, Andrew Morton wrote:
> > Please do not reinvent the mm/mempool.c functionality.
> > 
> > 'twould be better to just use it ;)
> 
> Unfortunately, in this instance, mempool is a slight overkill.  The
> problem is that we need to guarantee that a command (or set of commands)
> be available to a given device regardless of what's going on in the rest
> of the system.  Thus we might need a mempool for each active device,
> rather than a mempool for all devices and a mechanism for giving fine
> grained control to the pool depth per device.

A lot depends on the context of the allocation.  Can the caller sleep?
Is the caller using GFP_ATOMIC/__GFP_HIGH?

(What file-n-line should I be looking at, anyway?)

Bear in mind that on the swapout path, the calling process has PF_MEMALLOC
set.  This is a strong and successful mechanism - it allows the caller to dip
into the final page reserves which are denied to even GFP_ATOMIC allocations.
There's maybe a megabyte or two there.

Could be that there's no problem to be solved here.  It depends on whether
these allocations are occurring in process context or not.

>  Mempool would fit all of
> the above, I was just concerned that it looks to be a rather heavy
> addition (in terms of structure size) per device.

It's 40-odd bytes, plus 4*max_reservation bytes.  Fairly lean.