From: Ralf Baechle <ralf@conectiva.com.br>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Rik van Riel <riel@conectiva.com.br>,
Manfred Spraul <manfred@colorfullife.com>,
Andrea Arcangeli <andrea@suse.de>,
linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
torvalds@transmeta.com
Subject: Re: Purpose of the mm/slab.c changes
Date: Sat, 22 Sep 2001 14:28:47 +0200 [thread overview]
Message-ID: <20010922142847.A20641@dea.linux-mips.net> (raw)
In-Reply-To: <Pine.LNX.4.33L.0109091745130.21049-100000@duckman.distro.conectiva> <XFMail.20010909135844.davidel@xmailserver.org>
In-Reply-To: <XFMail.20010909135844.davidel@xmailserver.org>; from davidel@xmailserver.org on Sun, Sep 09, 2001 at 01:58:44PM -0700
On Sun, Sep 09, 2001 at 01:58:44PM -0700, Davide Libenzi wrote:
> >> Do You see it as a plus ?
> >> The new allocated slab will be very likely written ( w/o regard
> >> about the old content ) and an L2 mapping will generate
> >> invalidate traffic.
> >
> > If your invalidates are slower than your RAM, you should
> > consider getting another computer.
>
> You mean a Sun, that uses a separate bus for snooping ? :)
> Besides to not under estimate the cache coherency traffic ( that on many CPUs
> uses the main memory bus ) there's the fact that the old data eventually
> present in L2 won't be used by the new slab user.
That's actually what having a slab cache of pre-initialized elements tries
to achieve.
On anything that uses a MESI-like cache coherence protocol a cached dirty
cache line that is written to will not cause any coherency traffic and
thus be faster.
Ralf
--
"Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill.
next prev parent reply other threads:[~2001-09-22 12:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-09 11:05 Purpose of the mm/slab.c changes Manfred Spraul
2001-09-09 14:26 ` Andrea Arcangeli
2001-09-09 15:18 ` Manfred Spraul
2001-09-09 15:33 ` Andrea Arcangeli
2001-09-11 18:41 ` Manfred Spraul
2001-09-11 19:36 ` Andrea Arcangeli
2001-09-11 20:43 ` Manfred Spraul
2001-09-12 14:18 ` Andrea Arcangeli
2001-09-09 16:12 ` Alan Cox
2001-09-09 16:25 ` Linus Torvalds
2001-09-09 16:47 ` Alan Cox
2001-09-09 16:55 ` Manfred Spraul
2001-09-09 17:01 ` Linus Torvalds
2001-09-09 17:22 ` Manfred Spraul
2001-09-09 17:27 ` arjan
2001-09-09 17:35 ` Andrea Arcangeli
2001-09-09 17:30 ` Andrea Arcangeli
2001-09-09 17:59 ` Fwd: 2.4.10-pre6 ramdisk driver broken? won't compile Stephan Gutschke
2001-09-09 20:26 ` Purpose of the mm/slab.c changes Rik van Riel
2001-09-15 0:29 ` Albert D. Cahalan
2001-09-09 20:23 ` Rik van Riel
2001-09-09 20:44 ` Davide Libenzi
2001-09-09 20:45 ` Rik van Riel
2001-09-09 20:58 ` Davide Libenzi
2001-09-22 12:28 ` Ralf Baechle [this message]
2001-09-22 21:03 ` Davide Libenzi
2001-09-22 21:36 ` David S. Miller
2001-09-10 2:28 ` Daniel Phillips
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=20010922142847.A20641@dea.linux-mips.net \
--to=ralf@conectiva.com.br \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrea@suse.de \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=riel@conectiva.com.br \
--cc=torvalds@transmeta.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.