On Tuesday 25 October 2005 01:03, Jeff Dike wrote: > On Sat, Oct 22, 2005 at 06:38:16PM +0200, Blaisorblade wrote: > > In the write path of a ???lesystem, using > > GFP_KERNEL or GFP_ATOMIC will lead to deadlocks > > eventually. [...] GFP_NOFS is there for a reason, as is GFP_NOIO for > > block device drivers. > > I know about this, and this is another reason I'm not sending it in. I didn't know and you didn't mention, so I thought I'd better add about this. > I > don't really understand it either.
> If GFP_ATOMIC can block, then I don't > know what good it is. I _don't_ think it can block. I understand why GFP_KERNEL is broken there, but not why GFP_ATOMIC can't be used. The only pointer I found so far is that __GFP_HIGH allows the kernel to use up more memory without doing reclaim (see mm/page_alloc.c, calls to zone_watermark_ok). > > Which means that we _must_ ask for help from somebody else. > > Yup. > > Jeff -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ User-mode-linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
