[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PF_MEMALLOC in 2.6
On Fri, Aug 20, 2004 at 10:52:51AM +0200, Oliver Neukum wrote:
> Am Freitag, 20. August 2004 10:06 schrieb Nick Piggin:
> > >>So I'd say try to find a way to only use PF_MEMALLOC on behalf of
> > >>a PF_MEMALLOC thread or use a mempool or something.
> > >
> > >
> > > Then the SCSI layer should pass down the flag.
> > >
> >
> > It would be ideal from the memory allocator's point of view to do it
> > on a per-request basis like that.
> >
> > When the rubber hits the road, I think it is probably going to be very
> > troublesome to do it right that way. For example, what happens when
> > your usb-thingy-thread blocks on a memory allocation while handling a
> > read request, then the system gets low on memory and someone tries to
> > free some by submitting a write request to the USB device?
> The write request will have to wait.

> Storage cannot do concurrent IO.

I'm going to jump in here and ask a simple question, what is the
blocking point that stops writes happening concurrent with reads?

1024D/E65A7801 Zephaniah E. Hull <>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.

It was then I realized how dire my medical situation was. Here I was,
a network admin, unable to leave, and here was someone with a broken
network. And they didn't ask me to fix it. They didn't even try to
casually pry a hint out of me.
-- Ryan Tucker in the SDM.
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 14:05    [W:0.105 / U:20.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site