From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
linux-mm <linux-mm@kvack.org>,
Oleg Nesterov <onestero@redhat.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [rfc] lru_add_drain_all() vs isolation
Date: Tue, 08 Sep 2009 16:20:02 +0200 [thread overview]
Message-ID: <1252419602.7746.73.camel@twins> (raw)
In-Reply-To: <alpine.DEB.1.10.0909081000100.15723@V090114053VZO-1>
On Tue, 2009-09-08 at 10:03 -0400, Christoph Lameter wrote:
> On Tue, 8 Sep 2009, Peter Zijlstra wrote:
>
> > This is about avoiding work when there is non, clearly when an
> > application does use the kernel it creates work.
>
> Hmmm. The lru draining in page migration is to reduce the number of pages
> that are not on the lru to increase the chance of page migration to be
> successful. A page on a per cpu list cannot be drained.
>
> Reducing the number of cpus where we perform the drain results in
> increased likelyhood that we cannot migrate a page because its on the per
> cpu lists of a cpu not covered.
Did you even read the patch?
There is _no_ functional difference between before and after, except
less wakeups on cpus that don't have any __lru_cache_add activity.
If there's pages on the per cpu lru_add_pvecs list it will be present in
the mask and will be send a drain request. If its not, then it won't be
send.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
linux-mm <linux-mm@kvack.org>,
Oleg Nesterov <onestero@redhat.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [rfc] lru_add_drain_all() vs isolation
Date: Tue, 08 Sep 2009 16:20:02 +0200 [thread overview]
Message-ID: <1252419602.7746.73.camel@twins> (raw)
In-Reply-To: <alpine.DEB.1.10.0909081000100.15723@V090114053VZO-1>
On Tue, 2009-09-08 at 10:03 -0400, Christoph Lameter wrote:
> On Tue, 8 Sep 2009, Peter Zijlstra wrote:
>
> > This is about avoiding work when there is non, clearly when an
> > application does use the kernel it creates work.
>
> Hmmm. The lru draining in page migration is to reduce the number of pages
> that are not on the lru to increase the chance of page migration to be
> successful. A page on a per cpu list cannot be drained.
>
> Reducing the number of cpus where we perform the drain results in
> increased likelyhood that we cannot migrate a page because its on the per
> cpu lists of a cpu not covered.
Did you even read the patch?
There is _no_ functional difference between before and after, except
less wakeups on cpus that don't have any __lru_cache_add activity.
If there's pages on the per cpu lru_add_pvecs list it will be present in
the mask and will be send a drain request. If its not, then it won't be
send.
--
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:[~2009-09-08 14:20 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <dgRNo-3uc-5@gated-at.bofh.it>
[not found] ` <dhb9j-1hp-5@gated-at.bofh.it>
[not found] ` <dhcf5-263-13@gated-at.bofh.it>
2009-09-06 2:32 ` question on sched-rt group allocation cap: sched_rt_runtime_us Ani
2009-09-06 6:32 ` Mike Galbraith
2009-09-06 10:18 ` Mike Galbraith
[not found] ` <DDFD17CC94A9BD49A82147DDF7D545C54DC482@exchange.ZeugmaSystems.local>
2009-09-06 15:09 ` Mike Galbraith
2009-09-07 0:41 ` Anirban Sinha
[not found] ` <1252311463.7586.26.camel@marge.simson.net>
2009-09-07 11:06 ` [rfc] lru_add_drain_all() vs isolation Peter Zijlstra
2009-09-07 11:06 ` Peter Zijlstra
2009-09-07 13:35 ` Oleg Nesterov
2009-09-07 13:35 ` Oleg Nesterov
2009-09-07 13:53 ` Peter Zijlstra
2009-09-07 13:53 ` Peter Zijlstra
2009-09-07 14:18 ` Oleg Nesterov
2009-09-07 14:18 ` Oleg Nesterov
2009-09-07 14:25 ` Peter Zijlstra
2009-09-07 14:25 ` Peter Zijlstra
2009-09-07 23:56 ` KOSAKI Motohiro
2009-09-07 23:56 ` KOSAKI Motohiro
2009-09-08 8:20 ` Peter Zijlstra
2009-09-08 8:20 ` Peter Zijlstra
2009-09-08 10:06 ` KOSAKI Motohiro
2009-09-08 10:06 ` KOSAKI Motohiro
2009-09-08 10:20 ` Peter Zijlstra
2009-09-08 10:20 ` Peter Zijlstra
2009-09-08 11:41 ` KOSAKI Motohiro
2009-09-08 11:41 ` KOSAKI Motohiro
2009-09-08 12:05 ` Peter Zijlstra
2009-09-08 12:05 ` Peter Zijlstra
2009-09-08 14:03 ` Christoph Lameter
2009-09-08 14:03 ` Christoph Lameter
2009-09-08 14:20 ` Peter Zijlstra [this message]
2009-09-08 14:20 ` Peter Zijlstra
2009-09-08 15:22 ` Christoph Lameter
2009-09-08 15:22 ` Christoph Lameter
2009-09-08 15:27 ` Peter Zijlstra
2009-09-08 15:27 ` Peter Zijlstra
2009-09-08 15:32 ` Christoph Lameter
2009-09-08 15:32 ` Christoph Lameter
2009-09-09 4:27 ` KOSAKI Motohiro
2009-09-09 4:27 ` KOSAKI Motohiro
2009-09-09 14:08 ` Christoph Lameter
2009-09-09 14:08 ` Christoph Lameter
2009-09-09 23:43 ` KOSAKI Motohiro
2009-09-09 23:43 ` KOSAKI Motohiro
2009-09-10 18:03 ` Christoph Lameter
2009-09-10 18:03 ` Christoph Lameter
2009-09-09 15:39 ` Minchan Kim
2009-09-09 15:39 ` Minchan Kim
2009-09-09 16:18 ` Lee Schermerhorn
2009-09-09 16:18 ` Lee Schermerhorn
2009-09-09 16:46 ` Minchan Kim
2009-09-09 16:46 ` Minchan Kim
2009-09-09 23:58 ` KOSAKI Motohiro
2009-09-09 23:58 ` KOSAKI Motohiro
2009-09-10 1:00 ` Minchan Kim
2009-09-10 1:00 ` Minchan Kim
2009-09-10 1:15 ` KOSAKI Motohiro
2009-09-10 1:15 ` KOSAKI Motohiro
2009-09-10 1:23 ` Minchan Kim
2009-09-10 1:23 ` Minchan Kim
2009-09-09 2:06 ` KOSAKI Motohiro
2009-09-09 2:06 ` KOSAKI Motohiro
[not found] ` <DDFD17CC94A9BD49A82147DDF7D545C54DC483@exchange.ZeugmaSystems.local>
[not found] ` <DDFD17CC94A9BD49A82147DDF7D545C54DC485@exchange.ZeugmaSystems.local>
2009-09-07 0:28 ` question on sched-rt group allocation cap: sched_rt_runtime_us Anirban Sinha
2009-09-07 6:54 ` Mike Galbraith
[not found] ` <DDFD17CC94A9BD49A82147DDF7D545C54DC489@exchange.ZeugmaSystems.local>
2009-09-08 7:10 ` Anirban Sinha
2009-09-08 9:26 ` Mike Galbraith
2009-09-07 7:59 ` Peter Zijlstra
2009-09-07 8:24 ` Mike Galbraith
[not found] ` <DDFD17CC94A9BD49A82147DDF7D545C54DC487@exchange.ZeugmaSystems.local>
2009-09-08 7:08 ` Anirban Sinha
2009-09-08 8:42 ` Peter Zijlstra
2009-09-08 14:41 ` Anirban Sinha
[not found] ` <DDFD17CC94A9BD49A82147DDF7D545C54DC48B@exchange.ZeugmaSystems.local>
2009-09-08 17:41 ` Anirban Sinha
2009-09-08 19:06 ` Mike Galbraith
2009-09-08 19:34 ` Anirban Sinha
2009-09-09 4:10 ` Mike Galbraith
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=1252419602.7746.73.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=cl@linux-foundation.org \
--cc=efault@gmx.de \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=onestero@redhat.com \
/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.