All of lore.kernel.org
 help / color / mirror / Atom feed
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 V4] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Fri, 10 Jan 2014 09:36:56 +0100	[thread overview]
Message-ID: <20140110083656.GC26378@quack.suse.cz> (raw)
In-Reply-To: <1389295490-28707-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>

On Fri 10-01-14 00:54:50, Raghavendra K T wrote:
> We limit the number of readahead pages to 4k.
> 
> max_sane_readahead returns zero on the cpu having no local memory
> node. Fix that by returning a sanitized number of pages viz.,
> minimum of (requested pages, 4k, number of local free pages)
> 
> Result:
> fadvise experiment with FADV_WILLNEED on a x240 machine with 1GB testfile
> 32GB* 4G RAM  numa machine ( 12 iterations) yielded
> 
> kernel       Avg        Stddev
> base         7.264      0.56%
> patched      7.285      1.14%
  OK, looks good to me. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
>  mm/readahead.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> V4:  incorporated 16MB limit suggested by Linus for readahead and
> fixed transitioning to large readahead anomaly pointed by Andrew Morton with
> Honza's suggestion.
> 
> Test results shows no significant overhead with the current changes.
> 
> (Do I have to break patches into two??)
> 
> Suggestions/Comments please let me know.
> 
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 7cdbb44..2f561a0 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -237,14 +237,30 @@ 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;
> +	int nid;
> +
> +	nid = numa_node_id();
> +	sane_nr = min(nr, MAX_REMOTE_READAHEAD);
> +
> +	local_free_page = node_page_state(nid, NR_INACTIVE_FILE)
> +			  + node_page_state(nid, 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 node_present_pages(nid) ?
> +				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 V4] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Fri, 10 Jan 2014 09:36:56 +0100	[thread overview]
Message-ID: <20140110083656.GC26378@quack.suse.cz> (raw)
In-Reply-To: <1389295490-28707-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>

On Fri 10-01-14 00:54:50, Raghavendra K T wrote:
> We limit the number of readahead pages to 4k.
> 
> max_sane_readahead returns zero on the cpu having no local memory
> node. Fix that by returning a sanitized number of pages viz.,
> minimum of (requested pages, 4k, number of local free pages)
> 
> Result:
> fadvise experiment with FADV_WILLNEED on a x240 machine with 1GB testfile
> 32GB* 4G RAM  numa machine ( 12 iterations) yielded
> 
> kernel       Avg        Stddev
> base         7.264      0.56%
> patched      7.285      1.14%
  OK, looks good to me. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
>  mm/readahead.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> V4:  incorporated 16MB limit suggested by Linus for readahead and
> fixed transitioning to large readahead anomaly pointed by Andrew Morton with
> Honza's suggestion.
> 
> Test results shows no significant overhead with the current changes.
> 
> (Do I have to break patches into two??)
> 
> Suggestions/Comments please let me know.
> 
> diff --git a/mm/readahead.c b/mm/readahead.c
> index 7cdbb44..2f561a0 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -237,14 +237,30 @@ 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;
> +	int nid;
> +
> +	nid = numa_node_id();
> +	sane_nr = min(nr, MAX_REMOTE_READAHEAD);
> +
> +	local_free_page = node_page_state(nid, NR_INACTIVE_FILE)
> +			  + node_page_state(nid, 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 node_present_pages(nid) ?
> +				min(sane_nr, local_free_page / 2) : sane_nr;
>  }
>  
>  /*
> -- 
> 1.7.11.7
> 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2014-01-10  8:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 19:24 [RFC PATCH V4] mm readahead: Fix readahead fail for no local memory and limit readahead pages Raghavendra K T
2014-01-09 19:24 ` Raghavendra K T
2014-01-10  8:36 ` Jan Kara [this message]
2014-01-10  8:36   ` Jan Kara
2014-01-10  9:52   ` Jan Kara
2014-01-10  9:52     ` Jan Kara
2014-01-10 10:27     ` Raghavendra K T
2014-01-10 10:27       ` Raghavendra K T
2014-01-16 11:23     ` Raghavendra K T
2014-01-16 11:23       ` 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=20140110083656.GC26378@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.