All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andi Kleen <ak@muc.de>
Cc: linux-kernel@vger.kernel.org, Arjan van de Ven <arjan@infradead.org>
Subject: Re: 2.5isms
Date: Mon, 03 Jan 2005 11:44:41 +1100	[thread overview]
Message-ID: <41D89579.1080801@yahoo.com.au> (raw)
In-Reply-To: <m1brc882aw.fsf@muc.de>

Andi Kleen wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> writes:

>>even non HT CPUs possibly slightly more efficient WRT caching the stacks of
>>multiple processes?
> 
> 
> Not on x86 no because they normally have physically indexed caches
> (except for L1, but that is not really preserved over a context switch)
> HT is just a special case because two threads essentially share cache.
> 
> In theory it could help on non x86 CPUs with virtually indexed caches,
> but it is doubtful if they don't need more advanced forms of cache 
> colouring.
> 

That makes sense. I wonder if those architectures may just want to
implement it anyway. If this is such a win here, then it may be low
hanging fruit for those architectures.

But I guess there is something fundamentally a bit different when you
have two processes competing for L1 cache *at the same time*.

> 
>>Second, on what workloads does performance suffer, can you remember? I wonder
>>if natural variations in the stack pointer as the program runs would mitigate
>>the effect of this on all but micro benchmarks?
> 
> 
> iirc on lots of different workloas that run code on both virtual
> CPUs at the same time. Without it you would get L1 cache thrashing,
> which can slow things down quite a lot.
> 
> And yes it made a real difference. The P4 cache have some pecularities
> ("64K aliasing") that made the problem worse.
> 

Interesting, thanks.

  reply	other threads:[~2005-01-03  0:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-31 23:06 2.5isms Justin Pryzby
2005-01-01  2:34 ` 2.5isms Nick Piggin
2005-01-01  8:40   ` 2.5isms Arjan van de Ven
2005-01-01  9:13   ` 2.5isms Andi Kleen
2005-01-02  0:43     ` 2.5isms Nick Piggin
2005-01-02  8:58       ` 2.5isms Arjan van de Ven
2005-01-03  0:49         ` 2.5isms Nick Piggin
2005-01-02 12:04       ` 2.5isms Andi Kleen
2005-01-03  0:44         ` Nick Piggin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-07-03 20:01 "Will be removed in 2.4" Justin Pryzby
2003-12-30 21:30 ` 2.5isms Justin Pryzby
2004-01-03 15:18   ` 2.5isms Pavel Machek
2004-01-07  7:28   ` 2.5isms Justin Pryzby
2004-03-29 15:40   ` 2.5isms Pavel Machek

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=41D89579.1080801@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=ak@muc.de \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.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.