Re: [PATCH 17 of 39] IB/ipath - use more appropriate gfp flags

[Andrew Morton <akpm@osdl.org>]

"Bryan O'Sullivan" <bos@pathscale.com> 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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/