Since we are scrutinize sg page alloc code, I have a question here. Is
there any way to make the sg pages allocated noncacheable? If we use
sg in mmap mode, the reserved buffer could be changed by user space,
hardware as well as kernel. Uncached kernel access to these pages can
make PIO read/writes cache coherent.
Thanks,
Fajun
On 8/20/06, Andrew Morton <akpm@xxxxxxxx> wrote:
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
