"Bryan O'Sullivan" <[EMAIL PROTECTED]> wrote: > > diff -r fd5e733f02ac -r 9d943b828776 > drivers/infiniband/hw/ipath/ipath_file_ops.c > --- a/drivers/infiniband/hw/ipath/ipath_file_ops.c Thu Jun 29 14:33:25 > 2006 -0700 > +++ b/drivers/infiniband/hw/ipath/ipath_file_ops.c Thu Jun 29 14:33:25 > 2006 -0700 > @@ -705,6 +705,15 @@ static int ipath_create_user_egr(struct > unsigned e, egrcnt, alloced, egrperchunk, chunk, egrsize, egroff; > size_t size; > int ret; > + gfp_t gfp_flags; > + > + /* > + * GFP_USER, but without GFP_FS, so buffer cache can be > + * coalesced (we hope); otherwise, even at order 4, > + * heavy filesystem activity makes these fail, and we can > + * use compound pages. > + */ > + gfp_flags = __GFP_WAIT | __GFP_IO | __GFP_COMP;
Yes, GFP_NOFS|_GFP_COMP is reasonably strong - we can do swapout but not file pageout. I expect you'll find that a full GFP_KERNEL is OK here. The ~__GFP_FS is used to prevent the vm scanner from calling into ->writepage() and getting stuck on locks which the __alloc_pages() caller already holds. But ipathfs doesn't even implement ->writepage(), so I don't see any problem with setting __GFP_FS. If you're getting into trouble there then I'd recommend giving it a try - it will make memory reclaim more successful, especially with ext3, where a ->writepage often cleans the page synchronously without doing any IO. That being said, order-4 allocations will be fairly reliably unreliable. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
