"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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
