From: Jan Kara <jack@suse.cz>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Fengguang Wu <fengguang.wu@intel.com>,
David Cohen <david.a.cohen@linux.intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Damien Ramonda <damien.ramonda@intel.com>,
jack@suse.cz, Linus <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V3] mm readahead: Fix the readahead fail in case of empty numa node
Date: Mon, 6 Jan 2014 11:56:20 +0100 [thread overview]
Message-ID: <20140106105620.GC3312@quack.suse.cz> (raw)
In-Reply-To: <1389003715-29733-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>
On Mon 06-01-14 15:51:55, Raghavendra K T wrote:
> Currently, max_sane_readahead returns zero on the cpu with empty numa node,
> fix this by checking for potential empty numa node case during calculation.
> We also limit the number of readahead pages to 4k.
>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> The current patch limits the readahead into 4k pages (16MB was suggested
> by Linus). and also handles the case of memoryless cpu issuing readahead
> failures. We still do not consider [fm]advise() specific calculations
> here. I have dropped the iterating over numa node to calculate free page
> idea. I do not have much idea whether there is any impact on big
> streaming apps.. Comments/suggestions ?
As you say I would be also interested what impact this has on a streaming
application. It should be rather easy to check - create 1 GB file, drop
caches. Then measure how long does it take to open the file, call fadvise
FADV_WILLNEED, read the whole file (for a kernel with and without your
patch). Do several measurements so that we get some meaningful statistics.
Resulting numbers can then be part of the changelog. Thanks!
Honza
> mm/readahead.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 7cdbb44..be4d205 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -237,14 +237,25 @@ int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
> return ret;
> }
>
> +#define MAX_REMOTE_READAHEAD 4096UL
> /*
> * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
> * sensible upper limit.
> */
> unsigned long max_sane_readahead(unsigned long nr)
> {
> - return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE)
> - + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2);
> + unsigned long local_free_page;
> + unsigned long sane_nr = min(nr, MAX_REMOTE_READAHEAD);
> +
> + local_free_page = node_page_state(numa_node_id(), NR_INACTIVE_FILE)
> + + node_page_state(numa_node_id(), NR_FREE_PAGES);
> +
> + /*
> + * Readahead onto remote memory is better than no readahead when local
> + * numa node does not have memory. We sanitize readahead size depending
> + * on free memory in the local node but limiting to 4k pages.
> + */
> + return local_free_page ? min(sane_nr, local_free_page / 2) : sane_nr;
> }
>
> /*
> --
> 1.7.11.7
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Fengguang Wu <fengguang.wu@intel.com>,
David Cohen <david.a.cohen@linux.intel.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Damien Ramonda <damien.ramonda@intel.com>,
jack@suse.cz, Linus <torvalds@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V3] mm readahead: Fix the readahead fail in case of empty numa node
Date: Mon, 6 Jan 2014 11:56:20 +0100 [thread overview]
Message-ID: <20140106105620.GC3312@quack.suse.cz> (raw)
In-Reply-To: <1389003715-29733-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>
On Mon 06-01-14 15:51:55, Raghavendra K T wrote:
> Currently, max_sane_readahead returns zero on the cpu with empty numa node,
> fix this by checking for potential empty numa node case during calculation.
> We also limit the number of readahead pages to 4k.
>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> The current patch limits the readahead into 4k pages (16MB was suggested
> by Linus). and also handles the case of memoryless cpu issuing readahead
> failures. We still do not consider [fm]advise() specific calculations
> here. I have dropped the iterating over numa node to calculate free page
> idea. I do not have much idea whether there is any impact on big
> streaming apps.. Comments/suggestions ?
As you say I would be also interested what impact this has on a streaming
application. It should be rather easy to check - create 1 GB file, drop
caches. Then measure how long does it take to open the file, call fadvise
FADV_WILLNEED, read the whole file (for a kernel with and without your
patch). Do several measurements so that we get some meaningful statistics.
Resulting numbers can then be part of the changelog. Thanks!
Honza
> mm/readahead.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 7cdbb44..be4d205 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -237,14 +237,25 @@ int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
> return ret;
> }
>
> +#define MAX_REMOTE_READAHEAD 4096UL
> /*
> * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
> * sensible upper limit.
> */
> unsigned long max_sane_readahead(unsigned long nr)
> {
> - return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE)
> - + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2);
> + unsigned long local_free_page;
> + unsigned long sane_nr = min(nr, MAX_REMOTE_READAHEAD);
> +
> + local_free_page = node_page_state(numa_node_id(), NR_INACTIVE_FILE)
> + + node_page_state(numa_node_id(), NR_FREE_PAGES);
> +
> + /*
> + * Readahead onto remote memory is better than no readahead when local
> + * numa node does not have memory. We sanitize readahead size depending
> + * on free memory in the local node but limiting to 4k pages.
> + */
> + return local_free_page ? min(sane_nr, local_free_page / 2) : sane_nr;
> }
>
> /*
> --
> 1.7.11.7
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2014-01-06 10:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 10:21 [RFC PATCH V3] mm readahead: Fix the readahead fail in case of empty numa node Raghavendra K T
2014-01-06 10:21 ` Raghavendra K T
2014-01-06 10:56 ` Jan Kara [this message]
2014-01-06 10:56 ` Jan Kara
2014-01-08 8:37 ` Raghavendra K T
2014-01-08 8:37 ` Raghavendra K T
2014-01-08 10:38 ` Jan Kara
2014-01-08 10:38 ` Jan Kara
2014-01-08 11:59 ` Raghavendra K T
2014-01-08 11:59 ` Raghavendra K T
2014-01-06 22:13 ` Andrew Morton
2014-01-06 22:13 ` Andrew Morton
2014-01-08 8:49 ` Raghavendra K T
2014-01-08 8:49 ` Raghavendra K T
2014-01-08 10:47 ` Jan Kara
2014-01-08 10:47 ` Jan Kara
2014-01-08 11:57 ` Raghavendra K T
2014-01-08 11:57 ` Raghavendra K T
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=20140106105620.GC3312@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=damien.ramonda@intel.com \
--cc=david.a.cohen@linux.intel.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=raghavendra.kt@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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.