All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Andi Kleen <ak@suse.de>
Cc: torvalds@osdl.org, linux-arch@vger.kernel.org
Subject: Re: clear_user_highpage()
Date: Thu, 12 Aug 2004 13:30:24 -0700	[thread overview]
Message-ID: <20040812133024.36e5b7ee.davem@redhat.com> (raw)
In-Reply-To: <20040812220025.27cb260a.ak@suse.de>

On Thu, 12 Aug 2004 22:00:25 +0200
Andi Kleen <ak@suse.de> wrote:

> Well, the writes are usually faster. While they don't use the 
> cache they use special write combining buffers in the CPU
> that hold the data until it can blast out a full cache. Advantage
> is that it doesn't have to read anything first.

Sure. Sparc64 has this two, in fact is has a full 2K write
cache to absorb all of the cpu's write traffic.

> How effective this is depends on the CPU, in general newer 
> x86s tend to have much larger WC buffers than the previous 
> generation (e.g. Intel just enlarged them again in Prescott) 
> 
> Unlike all other stores on x86 they are also very lazily ordered
> and need explicit memory barriers.

The cache-bypassing 64-byte block stores behave this way
on sparc64.

> This still has the same problem: in the end the data
> is out of cache and when someone else needs it later they eat
> large penalties.

If it was in the cache to begin with, it will stay there.
This is the case the x86_64 bits lose for, they'll kick
the lines out.

If it is out of cache, no L2 cache lines are allocated.  This
is how x86_64 will perform.

I think the "hit" case behavior difference could make a difference.

  reply	other threads:[~2004-08-12 20:31 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-11 23:15 clear_user_highpage() David S. Miller
2004-08-11 23:31 ` clear_user_highpage() Benjamin Herrenschmidt
2004-08-11 23:55   ` clear_user_highpage() David S. Miller
2004-08-12  0:03     ` clear_user_highpage() Benjamin Herrenschmidt
2004-08-12  1:18       ` clear_user_highpage() William Lee Irwin III
2004-08-12  2:11       ` clear_user_highpage() Andi Kleen
2004-08-12  9:23         ` clear_user_highpage() Martin Schwidefsky
2004-08-11 23:46 ` clear_user_highpage() Linus Torvalds
2004-08-11 23:53   ` clear_user_highpage() David S. Miller
2004-08-12  0:00     ` clear_user_highpage() Linus Torvalds
2004-08-12  0:06       ` clear_user_highpage() Benjamin Herrenschmidt
2004-08-12  0:24         ` clear_user_highpage() David S. Miller
2004-08-12  0:23       ` clear_user_highpage() David S. Miller
2004-08-12  1:46         ` clear_user_highpage() Linus Torvalds
2004-08-12  2:51           ` clear_user_highpage() David S. Miller
2004-08-16  1:58         ` clear_user_highpage() Paul Mackerras
2004-08-12  2:08       ` clear_user_highpage() Andi Kleen
2004-08-12  2:45         ` clear_user_highpage() David S. Miller
2004-08-12  9:09           ` clear_user_highpage() Andi Kleen
2004-08-12 19:50             ` clear_user_highpage() David S. Miller
2004-08-12 20:00               ` clear_user_highpage() Andi Kleen
2004-08-12 20:30                 ` David S. Miller [this message]
2004-08-12 21:34               ` clear_user_highpage() Matthew Wilcox
2004-08-13  8:16                 ` clear_user_highpage() David Mosberger
2004-08-12  0:00   ` clear_user_highpage() Benjamin Herrenschmidt
2004-08-12  0:21     ` clear_user_highpage() Linus Torvalds
2004-08-12  0:46   ` clear_user_highpage() William Lee Irwin III
2004-08-12  1:01     ` clear_user_highpage() David S. Miller
2004-08-12  2:18     ` clear_user_highpage() Linus Torvalds
2004-08-12  2:43       ` clear_user_highpage() David S. Miller
2004-08-12  4:19         ` clear_user_highpage() Linus Torvalds
2004-08-12  4:46           ` clear_user_highpage() William Lee Irwin III
2004-08-15  6:22             ` clear_user_highpage() Andrew Morton
2004-08-15  6:38               ` clear_user_highpage() William Lee Irwin III
2004-08-12  2:57       ` clear_user_highpage() David S. Miller
2004-08-12  3:20       ` clear_user_highpage() William Lee Irwin III
2004-08-13 21:41       ` clear_user_highpage() David S. Miller
2004-08-16 13:00         ` clear_user_highpage() David Mosberger
2004-08-22 19:51           ` clear_user_highpage() Linus Torvalds
2005-09-17 19:01             ` clear_user_highpage() Andi Kleen
2005-09-17 19:16               ` clear_user_highpage() Andi Kleen

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=20040812133024.36e5b7ee.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=ak@suse.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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.