Messages in this thread Patch in this message | | | Date | Fri, 3 Dec 2004 17:18:35 +1100 | From | Nathan Scott <> | Subject | Re: Kernel 2.6.9 Multiple Page Allocation Failures |
| |
Hi there,
On Thu, Dec 02, 2004 at 02:56:10PM -0800, Andrew Morton wrote: > Stefan Schmidt <zaphodb@zaphods.net> wrote: > > > > and ~80kpps in each direction at ~44k interrupts/s, so the problematic > > combination seems to be many open files, high i/o transaction rate or > > troughput and heavy networking load. (tso currently on) > > Caching on ext2-fs in general seemed to generate less page allocation errors > > than on xfs and none of the traces i looked over so far showed involvement > > of the filesystem i.e. were all triggered by alloc_skb. > > hm, OK, interesting. > > It's quite possible that XFS is performing rather too many GFP_ATOMIC > allocations and is depleting the page reserves. Although increasing > /proc/sys/vm/min_free_kbytes should help there. > > Nathan, it would be a worthwhile exercise to consider replacing GFP_ATOMIC > with (GFP_ATOMIC & ~ __GFP_HIGH) where appropriate. > ...
(i.e. zero? so future-proofing for if GFP_ATOMIC != __GFP_HIGH?)
> If there are places in XFS where it only needs one of these two behaviours, > it would be good to select just that one.
OK, I took a quick look through - there's two places where we use GFP_ATOMIC at the moment. One is a log debug/tracing chunk of code, wont be coming into play here, I'll go back and rework that later. The second is in the metadata buffering code, and is in a spot where we can cope with a failure (don't need to dip into emergency pools at all) but looks like we're avoiding sleeping there.
Does this patch improve things for your workload, Stefan?
cheers.
-- Nathan
Index: xfs-linux-2.6/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- xfs-linux-2.6.orig/fs/xfs/linux-2.6/xfs_buf.c +++ xfs-linux-2.6/fs/xfs/linux-2.6/xfs_buf.c @@ -183,7 +183,7 @@ { a_list_t *aentry; - aentry = kmalloc(sizeof(a_list_t), GFP_ATOMIC); + aentry = kmalloc(sizeof(a_list_t), (GFP_ATOMIC & ~__GFP_HIGH)); if (aentry) { spin_lock(&as_lock); aentry->next = as_free_head; - 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/
| |