On Sun, 20 Aug 2006 12:07:21 +0200 Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote: > On Sat, 2006-08-19 at 21:00 -0400, Douglas Gilbert wrote: > > Matthew Wilcox wrote: > > > On Sat, Aug 19, 2006 at 10:41:09AM -0700, Andrew Morton wrote: > > >> ow, GFP_ATOMIC is bad. Can we avoid that? > > > > > > I believe all the GFP_ATOMIC calls in sg.c can be downgraded to > > > GFP_KERNEL. > > > > Well, if memory serves, we have been around this loop > > before. The GFP_ATOMIC flags were removed, users > > complained about unexplained, unbounded waits unrelated > > to the SCSI transport or device. > > this is not a fair answer... in a way GFP_ATOMIC is an antisocial > behavior that should only be done when there is an absolute need. You'll > dip into the VM reserves by using it after all! Thing is, SG is (for some reason) using order-3 allocations. Those can indeed send the VM into a large amount of reclaim when combined with GFP_KERNEL. SG will fall back to lower-order pages if the higher-order attempt didn't work out. If we were to fine-tune this then perhaps: alloc_pages(GFP_ATOMIC & ~__GFP_HIGH, 3) alloc_pages(GFP_ATOMIC & ~__GFP_HIGH, 2) alloc_pages(GFP_ATOMIC & ~__GFP_HIGH, 1) alloc_pages(GFP_KERNEL, 0) would suit. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
