[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1402101333160.15624@chino.kir.corp.google.com>
Date: Mon, 10 Feb 2014 13:35:35 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Fengguang Wu <fengguang.wu@...el.com>,
David Cohen <david.a.cohen@...ux.intel.com>,
Al Viro <viro@...iv.linux.org.uk>,
Damien Ramonda <damien.ramonda@...el.com>,
Jan Kara <jack@...e.cz>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local
memory and limit readahead pages
On Mon, 10 Feb 2014, Raghavendra K T wrote:
> So I understood that you are suggesting implementations like below
>
> 1) I do not have problem with the below approach, I could post this in
> next version.
> ( But this did not include 4k limit Linus mentioned to apply)
>
> unsigned long max_sane_readahead(unsigned long nr)
> {
> unsigned long local_free_page;
> int nid;
>
> nid = numa_mem_id();
>
> /*
> * We sanitize readahead size depending on free memory in
> * the local node.
> */
> local_free_page = node_page_state(nid, NR_INACTIVE_FILE)
> + node_page_state(nid, NR_FREE_PAGES);
> return min(nr, local_free_page / 2);
> }
>
> 2) I did not go for below because Honza (Jan Kara) had some
> concerns for 4k limit for normal case, and since I am not
> the expert, I was waiting for opinions.
>
> unsigned long max_sane_readahead(unsigned long nr)
> {
> unsigned long local_free_page, sane_nr;
> int nid;
>
> nid = numa_mem_id();
> /* limit the max readahead to 4k pages */
> sane_nr = min(nr, MAX_REMOTE_READAHEAD);
>
> /*
> * We sanitize readahead size depending on free memory in
> * the local node.
> */
> local_free_page = node_page_state(nid, NR_INACTIVE_FILE)
> + node_page_state(nid, NR_FREE_PAGES);
> return min(sane_nr, local_free_page / 2);
> }
>
I have no opinion on the 4KB pages, either of the above is just fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists