linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gilad Ben-Yossef <gilad@benyossef.com>
To: Mel Gorman <mgorman@suse.de>, Chris Metcalf <cmetcalf@tilera.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
	Matt Mackall <mpm@selenic.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	Rik van Riel <riel@redhat.com>, Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH v4 5/5] mm: Only IPI CPUs to drain local pages if they exist
Date: Fri, 30 Dec 2011 22:29:02 +0200	[thread overview]
Message-ID: <CAOtvUMdCJEcDBD2KJ0T=Fygnag4sXaDMziYaH1oyeoQ42iZjaQ@mail.gmail.com> (raw)
In-Reply-To: <20111230160857.GH15729@suse.de>

On Fri, Dec 30, 2011 at 6:08 PM, Mel Gorman <mgorman@suse.de> wrote:
> On Fri, Dec 30, 2011 at 10:25:46AM -0500, Chris Metcalf wrote:

>> Alternately, since we really don't want more than one cpu running the drain
>> code anyway, you could imagine using a static cpumask, along with a lock to
>> serialize attempts to drain all the pages.  (Locking here would be tricky,
>> since we need to run on_each_cpu with interrupts enabled, but there's
>> probably some reasonable way to make it work.)
>>
>
> Good suggestion, that would at least shut up my complaining
> about allocation costs! A statically-declared mutex similar
> to hugetlb_instantiation_mutex should do it. The context that
> drain_all_pages is called from will have interrupts enabled.
>
> Serialising processes entering direct reclaim may result in some stalls
> but overall I think the impact of that would be less than increasing
> memory pressure when low on memory.
>

Chris, I like the idea :-)

Actually, assuming for a second that on_each_cpu* and underlying code
wont mind if the cpumask will change mid call (I know it does, just thinking out
loud), you could say you don't even need the lock if you careful in how you
set/unset the per cpu bits of the cpumask, since they track the same thing...

Of course, it'll still cause a load of cache line bouncing, so maybe
it's not worth it.

> It would still be nice to have some data on how much IPIs are reduced
> in practice to confirm the patch really helps.

I agree. I'll prepare the patch and will present the data.

Thanks!
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"Unfortunately, cache misses are an equal opportunity pain provider."
-- Mike Galbraith, LKML

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-12-30 20:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22 11:08 [PATCH v4 0/5] Reduce cross CPU IPI interference Gilad Ben-Yossef
2011-11-22 11:08 ` [PATCH v4 1/5] smp: Introduce a generic on_each_cpu_mask function Gilad Ben-Yossef
2011-11-22 11:08 ` [PATCH v4 2/5] arm: Move arm over to generic on_each_cpu_mask Gilad Ben-Yossef
2011-11-22 21:00   ` Russell King - ARM Linux
2011-11-23  6:47     ` Gilad Ben-Yossef
2011-11-22 11:08 ` [PATCH v4 3/5] tile: Move tile to use " Gilad Ben-Yossef
2011-11-22 11:08 ` [PATCH v4 4/5] slub: Only IPI CPUs that have per cpu obj to flush Gilad Ben-Yossef
2011-11-23  6:23   ` Pekka Enberg
2011-11-23  6:57     ` Pekka Enberg
2011-11-23  7:52       ` Gilad Ben-Yossef
2012-01-01 12:41     ` Avi Kivity
2012-01-01 16:12       ` Gilad Ben-Yossef
2012-01-01 16:50         ` Avi Kivity
2012-01-02 11:59           ` Gilad Ben-Yossef
2012-01-02 13:30             ` Avi Kivity
2012-01-08 16:13               ` Gilad Ben-Yossef
2012-01-08 16:15                 ` Avi Kivity
2011-11-22 11:08 ` [PATCH v4 5/5] mm: Only IPI CPUs to drain local pages if they exist Gilad Ben-Yossef
2011-11-23  7:45   ` Pekka Enberg
2011-12-23 10:28   ` Mel Gorman
2011-12-25  9:39     ` Gilad Ben-Yossef
2011-12-30 15:04       ` Mel Gorman
2011-12-30 15:25         ` Chris Metcalf
2011-12-30 16:08           ` Mel Gorman
2011-12-30 20:29             ` Gilad Ben-Yossef [this message]
2012-01-01  8:03               ` Gilad Ben-Yossef
2011-12-30 20:16         ` Gilad Ben-Yossef
2011-11-23  1:36 ` [PATCH v4 0/5] Reduce cross CPU IPI interference Chris Metcalf
2011-11-23  6:52   ` Gilad Ben-Yossef

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='CAOtvUMdCJEcDBD2KJ0T=Fygnag4sXaDMziYaH1oyeoQ42iZjaQ@mail.gmail.com' \
    --to=gilad@benyossef.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=cmetcalf@tilera.com \
    --cc=fweisbec@gmail.com \
    --cc=levinsasha928@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mgorman@suse.de \
    --cc=mpm@selenic.com \
    --cc=penberg@kernel.org \
    --cc=riel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox