From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
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>,
rientjes@google.com, Linus <torvalds@linux-foundation.org>,
nacc@linux.vnet.ibm.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V6 ] mm readahead: Fix readahead fail for memoryless cpu and limit readahead pages
Date: Tue, 18 Feb 2014 17:34:54 +0530 [thread overview]
Message-ID: <53034C66.90707@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140218094920.GB29660@quack.suse.cz>
On 02/18/2014 03:19 PM, Jan Kara wrote:
> On Tue 18-02-14 12:55:38, Raghavendra K T wrote:
>> Currently max_sane_readahead() returns zero on the cpu having no local memory node
>> which leads to readahead failure. Fix the readahead failure by returning
>> minimum of (requested pages, 512). Users running application on a memory-less cpu
>> which needs readahead such as streaming application see considerable boost in the
>> performance.
>>
>> Result:
>> fadvise experiment with FADV_WILLNEED on a PPC machine having memoryless CPU
>> with 1GB testfile ( 12 iterations) yielded around 46.66% improvement.
>>
>> fadvise experiment with FADV_WILLNEED on a x240 machine with 1GB testfile
>> 32GB* 4G RAM numa machine ( 12 iterations) showed no impact on the normal
>> NUMA cases w/ patch.
> Can you try one more thing please? Compare startup time of some big
> executable (Firefox or LibreOffice come to my mind) for the patched and
> normal kernel on a machine which wasn't hit by this NUMA issue. And don't
> forget to do "echo 3 >/proc/sys/vm/drop_caches" before each test to flush
> the caches. If this doesn't show significant differences, I'm OK with the
> patch.
>
Thanks Honza, I checked with firefox (starting to particular point)..
I do not see any difference. Both the case took around 14sec.
( some time it is even faster.. may be because we do not do free page
calculation?. )
--
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: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
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>,
rientjes@google.com, Linus <torvalds@linux-foundation.org>,
nacc@linux.vnet.ibm.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V6 ] mm readahead: Fix readahead fail for memoryless cpu and limit readahead pages
Date: Tue, 18 Feb 2014 17:34:54 +0530 [thread overview]
Message-ID: <53034C66.90707@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140218094920.GB29660@quack.suse.cz>
On 02/18/2014 03:19 PM, Jan Kara wrote:
> On Tue 18-02-14 12:55:38, Raghavendra K T wrote:
>> Currently max_sane_readahead() returns zero on the cpu having no local memory node
>> which leads to readahead failure. Fix the readahead failure by returning
>> minimum of (requested pages, 512). Users running application on a memory-less cpu
>> which needs readahead such as streaming application see considerable boost in the
>> performance.
>>
>> Result:
>> fadvise experiment with FADV_WILLNEED on a PPC machine having memoryless CPU
>> with 1GB testfile ( 12 iterations) yielded around 46.66% improvement.
>>
>> fadvise experiment with FADV_WILLNEED on a x240 machine with 1GB testfile
>> 32GB* 4G RAM numa machine ( 12 iterations) showed no impact on the normal
>> NUMA cases w/ patch.
> Can you try one more thing please? Compare startup time of some big
> executable (Firefox or LibreOffice come to my mind) for the patched and
> normal kernel on a machine which wasn't hit by this NUMA issue. And don't
> forget to do "echo 3 >/proc/sys/vm/drop_caches" before each test to flush
> the caches. If this doesn't show significant differences, I'm OK with the
> patch.
>
Thanks Honza, I checked with firefox (starting to particular point)..
I do not see any difference. Both the case took around 14sec.
( some time it is even faster.. may be because we do not do free page
calculation?. )
next prev parent reply other threads:[~2014-02-18 11:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 7:25 [PATCH V6 ] mm readahead: Fix readahead fail for memoryless cpu and limit readahead pages Raghavendra K T
2014-02-18 7:25 ` Raghavendra K T
2014-02-18 9:49 ` Jan Kara
2014-02-18 9:49 ` Jan Kara
2014-02-18 12:04 ` Raghavendra K T [this message]
2014-02-18 12:04 ` Raghavendra K T
2014-02-18 12:04 ` Jan Kara
2014-02-18 12:04 ` Jan Kara
2014-03-17 2:07 ` Madper Xie
2014-03-17 2:07 ` Madper Xie
2014-03-18 7:13 ` Raghavendra K T
2014-03-18 7:13 ` Raghavendra K T
2014-02-18 22:23 ` David Rientjes
2014-02-18 22:23 ` David Rientjes
2014-02-18 22:38 ` Andrew Morton
2014-02-18 22:38 ` Andrew Morton
2014-02-18 22:46 ` David Rientjes
2014-02-18 22:46 ` David Rientjes
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=53034C66.90707@linux.vnet.ibm.com \
--to=raghavendra.kt@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=damien.ramonda@intel.com \
--cc=david.a.cohen@linux.intel.com \
--cc=fengguang.wu@intel.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nacc@linux.vnet.ibm.com \
--cc=rientjes@google.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.