Re: scsi command slab allocation under memory pressure

Doug Ledford
2003-02-03T22:55:50Z

On Fri, Jan 31, 2003 at 12:44:12PM -0800, Andrew Morton wrote:
> 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.

I think the case is that there is no problem to be solved. One command
per host is enough to keep each host running, and that's enough to keep
the system running. If we are ever low enough on mem that we get down to
failing scsi command allocations, the system is already hurting. The
complaint was that a device doing something other than swap could starve a
swap device. I don't buy that. If the device is doing constant reads
then it's going to run out of mem eventually and block just like our
allocations are, if it's writing then it very likely is freeing up just as
many pages as the swap operation would be. In short, I think if we keep
the disk subsystem running, even if crippled with just one command, the
problem becomes self correcting and there isn't much for us to solve. Of
course, that's just my 5 minute analysis, someone feel free to prove me
wrong.

--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606