linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gilad Ben-Yossef <gilad@benyossef.com>
To: Christoph Lameter <cl@gentwo.org>
Cc: Shaohua Li <shaohua.li@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Russell King <linux@arm.linux.org.uk>,
	Chris Metcalf <cmetcalf@tilera.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH 4/5] mm: Only IPI CPUs to drain local pages if they exist
Date: Tue, 27 Sep 2011 10:27:06 +0300	[thread overview]
Message-ID: <CAOtvUMcvwWFxxxv7tsOj6FO-wrHAU8EYc+U=9u8yT=cz7XajBA@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1109261023400.24164@router.home>

Hi,

On Mon, Sep 26, 2011 at 6:24 PM, Christoph Lameter <cl@gentwo.org> wrote:
> On Mon, 26 Sep 2011, Gilad Ben-Yossef wrote:
>
>> I do not know if these scenarios warrant the additional overhead,
>> certainly not in all situations. Maybe the right thing is to make it a
>> config option dependent. As I stated in the patch description, that is
>> one of the thing I'm interested in feedback on.
>
> The flushing of the per cpu pages only done when kmem_cache_shrink() is
> run or when a slab cache is closed. And for diagnostics. So its rare and
> not performance critical.

Yes, I understand. The problem is it pops up in the oddest of place.
An example is in order:

The Ipath Infiniband hardware exports a char device interface to user space.
When a user opens the char device and configures a port, a kmem_cache
is created.
When the user later closes the fd, the release method of the char
device destroys
the kmem_cache.

So, if I have some high performance server with 128 processors, and
I've dedicated
127 processors to run my CPU bound computing tasks (and made sure the interrupt
are serviced by the last CPU)  and then run a shell on  the lone admin
CPU to do a backup,
I can interrupt my 127 CPUs doing computational tasks, even though
they have nothing to do
with Infiniband, or backup and have never allocated a single buffer
form that cache.

I believe there is a similar scenario with software raid if I change
RAID configs and several
other places. In fact, I'm guessing many of the lines that pop up when
doing the following
grep hide a similar scenario:

$ git grep kmem_cache_destroy . | grep '\->'

I hope this explains my interest.

My hope is to come up with a way to do more code on the CPU doing the
flush_all (which
as you said is a rare and none performance critical code path anyway)
and by that gain the ability
to do the job without interrupting CPUs that do not need to flush
their per cpu pages.

Thanks,
Gilad







>
>
>



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

"I've seen things you people wouldn't believe. Goto statements used to
implement co-routines. I watched C structures being stored in
registers. All those moments will be lost in time... like tears in
rain... Time to die. "

--
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-09-27  7:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-25  8:54 [PATCH 0/5] Reduce cross CPU IPI interference Gilad Ben-Yossef
2011-09-25  8:54 ` [PATCH 1/5] smp: Introduce a generic on_each_cpu_mask function Gilad Ben-Yossef
2011-09-25 11:37   ` Sasha Levin
2011-09-26  8:48   ` Peter Zijlstra
2011-09-25  8:54 ` [PATCH 2/5] arm: Move arm over to generic on_each_cpu_mask Gilad Ben-Yossef
2011-09-25  8:54 ` [PATCH 3/5] tile: Move tile to use " Gilad Ben-Yossef
2011-09-25  8:54 ` [PATCH 4/5] mm: Only IPI CPUs to drain local pages if they exist Gilad Ben-Yossef
2011-09-26  1:52   ` Shaohua Li
2011-09-26  6:47     ` Gilad Ben-Yossef
2011-09-26 15:24       ` Christoph Lameter
2011-09-27  7:27         ` Gilad Ben-Yossef [this message]
2011-09-27 16:13           ` Christoph Lameter
2011-09-26  7:28   ` Peter Zijlstra
2011-09-26  8:39     ` Gilad Ben-Yossef
2011-09-26  7:29   ` Peter Zijlstra
2011-09-25  8:54 ` [PATCH 5/5] slub: Only IPI CPUs that have per cpu obj to flush Gilad Ben-Yossef
2011-09-26  6:54   ` Pekka Enberg
2011-09-26  7:36     ` Peter Zijlstra
2011-09-26  8:07       ` Gilad Ben-Yossef
2011-09-26 10:03         ` Pekka Enberg
2011-09-26  8:10     ` Gilad Ben-Yossef
2011-09-26  7:33   ` Peter Zijlstra
2011-09-26  8:35     ` Gilad Ben-Yossef
2011-09-26  9:28       ` Pekka Enberg
2011-09-26  9:45       ` Peter Zijlstra
2011-09-26 12:05         ` Gilad Ben-Yossef
2011-09-26 13:49           ` Gilad Ben-Yossef
2011-09-26  7:20 ` [PATCH 0/5] Reduce cross CPU IPI interference Peter Zijlstra
2011-09-26  8:43   ` Gilad Ben-Yossef
2011-09-26  8:46     ` Peter Zijlstra
2011-09-28 13:00 ` Chris Metcalf
2011-10-02  8:44   ` Gilad Ben-Yossef
2011-10-02 14:58     ` Chris Metcalf

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='CAOtvUMcvwWFxxxv7tsOj6FO-wrHAU8EYc+U=9u8yT=cz7XajBA@mail.gmail.com' \
    --to=gilad@benyossef.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cl@gentwo.org \
    --cc=cmetcalf@tilera.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mpm@selenic.com \
    --cc=penberg@kernel.org \
    --cc=shaohua.li@intel.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