From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Aubrey <aubreylee@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: The VFS cache is not freed when there is not enough free memory to allocate
Date: Wed, 22 Nov 2006 09:43:56 +0100 [thread overview]
Message-ID: <1164185036.5968.179.camel@twins> (raw)
In-Reply-To: <6d6a94c50611212351if1701ecx7b89b3fe79371554@mail.gmail.com>
On Wed, 2006-11-22 at 15:51 +0800, Aubrey wrote:
> Hi all,
>
> We are working on the blackfin uClinux platform and we encountered the
> following problem.
> The attached patch can work around this issue and I post it here to
> find better solution.
> root:/mnt> ./t
> Alloc 8 MB !
> t: page allocation failure. order:9, mode:0x40d0
^^^^^^^
Such high order allocs rarely succeed after bootup. The proposed patch
will hardly help that more than lumpy reclaim will. Please see the
threads on Mel Gorman's Anti-Fragmentation and Linear/Lumpy reclaim in
the linux-mm archives.
> From: Aubrey.Li <aubrey.li@analog.com>
> Date: Wed, 22 Nov 2006 15:10:18 +0800
> Subject: [PATCH] Drop VFS cache when there is not enough free memory to allocate
>
> Signed-off-by: Aubrey.Li <aubrey.li@analog.com>
> ---
> mm/page_alloc.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index bf2f6cf..62559fd 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1039,6 +1039,11 @@ restart:
> if (page)
> goto got_pg;
>
> +#if defined(CONFIG_EMBEDDED) && !defined(CONFIG_MMU)
> + drop_pagecache();
> + drop_slab();
> +#endif
> +
> /* This allocation should allow future memory freeing. */
>
> if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
> --
> The patch drop the page cache and slab and then give a new chance to
> get more free pages. Applied this patch, my test application can
> allocate memory sucessfully and drop the cache and slab as well. See
> below:
> ================================
> root:/mnt> ./t
> Alloc 8 MB !
> alloc successful
Pure luck, there are workloads where there just would not have been any
order 9 contiguous block freeable (think where each 9th order block
would contain at least one active inode).
> I know performance is important for linux, and VFS cache obviously
> improve the performance when implement file operation. But for
> embedded system, we'll try our best to make the application executable
> rather than hanging system to guarantee the system performance.
>
> Any suggestions and solutions are really appreciated!
Try Mel's patches and wait for the next Lumpy reclaim posting.
The lack of a MMU on your system makes it very hard not to rely on
higher order allocations, because even user-space allocs need to be
physically contiguous. But please take that into consideration when
writing software.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Aubrey <aubreylee@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: The VFS cache is not freed when there is not enough free memory to allocate
Date: Wed, 22 Nov 2006 09:43:56 +0100 [thread overview]
Message-ID: <1164185036.5968.179.camel@twins> (raw)
In-Reply-To: <6d6a94c50611212351if1701ecx7b89b3fe79371554@mail.gmail.com>
On Wed, 2006-11-22 at 15:51 +0800, Aubrey wrote:
> Hi all,
>
> We are working on the blackfin uClinux platform and we encountered the
> following problem.
> The attached patch can work around this issue and I post it here to
> find better solution.
> root:/mnt> ./t
> Alloc 8 MB !
> t: page allocation failure. order:9, mode:0x40d0
^^^^^^^
Such high order allocs rarely succeed after bootup. The proposed patch
will hardly help that more than lumpy reclaim will. Please see the
threads on Mel Gorman's Anti-Fragmentation and Linear/Lumpy reclaim in
the linux-mm archives.
> From: Aubrey.Li <aubrey.li@analog.com>
> Date: Wed, 22 Nov 2006 15:10:18 +0800
> Subject: [PATCH] Drop VFS cache when there is not enough free memory to allocate
>
> Signed-off-by: Aubrey.Li <aubrey.li@analog.com>
> ---
> mm/page_alloc.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index bf2f6cf..62559fd 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1039,6 +1039,11 @@ restart:
> if (page)
> goto got_pg;
>
> +#if defined(CONFIG_EMBEDDED) && !defined(CONFIG_MMU)
> + drop_pagecache();
> + drop_slab();
> +#endif
> +
> /* This allocation should allow future memory freeing. */
>
> if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
> --
> The patch drop the page cache and slab and then give a new chance to
> get more free pages. Applied this patch, my test application can
> allocate memory sucessfully and drop the cache and slab as well. See
> below:
> ================================
> root:/mnt> ./t
> Alloc 8 MB !
> alloc successful
Pure luck, there are workloads where there just would not have been any
order 9 contiguous block freeable (think where each 9th order block
would contain at least one active inode).
> I know performance is important for linux, and VFS cache obviously
> improve the performance when implement file operation. But for
> embedded system, we'll try our best to make the application executable
> rather than hanging system to guarantee the system performance.
>
> Any suggestions and solutions are really appreciated!
Try Mel's patches and wait for the next Lumpy reclaim posting.
The lack of a MMU on your system makes it very hard not to rely on
higher order allocations, because even user-space allocs need to be
physically contiguous. But please take that into consideration when
writing software.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-11-22 8:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-22 7:51 The VFS cache is not freed when there is not enough free memory to allocate Aubrey
2006-11-22 7:51 ` Aubrey
2006-11-22 8:43 ` Peter Zijlstra [this message]
2006-11-22 8:43 ` Peter Zijlstra
2006-11-22 10:02 ` Aubrey
2006-11-22 10:02 ` Aubrey
2006-11-22 10:42 ` Peter Zijlstra
2006-11-22 10:42 ` Peter Zijlstra
2006-11-22 11:09 ` Aubrey
2006-11-22 11:09 ` Aubrey
2006-11-27 1:34 ` Mike Frysinger
2006-11-27 1:34 ` Mike Frysinger
2006-11-27 7:39 ` Nick Piggin
2006-11-27 7:39 ` Nick Piggin
2006-11-29 7:17 ` Sonic Zhang
2006-11-29 7:17 ` Sonic Zhang
2006-11-29 9:27 ` Aubrey
2006-11-29 9:27 ` Aubrey
2006-11-29 9:30 ` Nick Piggin
2006-11-29 9:30 ` Nick Piggin
2006-11-30 12:54 ` Aubrey
2006-11-30 12:54 ` Aubrey
2006-11-30 21:18 ` Nick Piggin
2006-11-30 21:18 ` Nick Piggin
2006-12-01 10:00 ` Aubrey
2006-12-01 10:00 ` Aubrey
-- strict thread matches above, loose matches on Subject: below --
2006-11-28 13:29 Robin Getz
2006-11-28 14:41 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1164185036.5968.179.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=aubreylee@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.