Re: [PATCH 17 of 39] IB/ipath - use more appropriate gfp flags
From: Andrew Morton <hidden>
Date: 2006-06-30 00:03:16
Also in:
lkml
"Bryan O'Sullivan" [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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.