Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261685AbSIXOJr>; Tue, 24 Sep 2002 10:09:47 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261686AbSIXOJr>; Tue, 24 Sep 2002 10:09:47 -0400
Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:56825 "EHLO
	warthog.cambridge.redhat.com") by vger.kernel.org with ESMTP
	id <S261685AbSIXOJA>; Tue, 24 Sep 2002 10:09:00 -0400
To: Ingo Molnar <mingo@redhat.com>
cc: David Howells <dhowells@redhat.com>, arjanv@redhat.com, dwmw2@redhat.com,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] per-interrupt stacks - try 2 
In-Reply-To: Message from Ingo Molnar <mingo@redhat.com> 
   of "Sun, 15 Sep 2002 07:51:39 EDT." <Pine.LNX.4.44.0209150747510.19045-100000@devserv.devel.redhat.com> 
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i686-pc-linux-gnu)
 MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 16 Sep 2002 15:09:55 +0100
Message-ID: <4038.1032185395@warthog.cambridge.redhat.com>
From: David Howells <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1448
Lines: 35


> > Do you have benchmarks or something to show that is this actually a
> > _significant_ problem?
> 
> you need benchmarks to tell that pure per-IRQ stacks are bad for SMP
> performance?

No. I asked how _significant_ the difference is, as compared to the rest of
the accesses it makes.

> per-IRQ+per-CPU and pure per-CPU IRQ stacks should perform rougly equally
> well on SMP - with per-CPU IRQ stacks having lower runtime setup cost.

There are problems with purely per-CPU stacks if you run with interrupts
enabled. You theoretically ought to have a stack big enough to allow all
possible interrupts to be nested on one CPU.

And having non-uniform stack sizes of course introduces other
problems... notably the fact that you can no longer locate the thread_info
struct by means of AND-ing the stack pointer.

> there's a difference between bouncing 1-2 cachelines and bouncing a *full,
> dirtied stack*. The irq_desc[] bouncing is pretty much unavoidable (IRQs do
> need some global state) - the stack bouncing is just plain stupid and
> perfectly avoidable.

I wonder if it might be possible to invalidate just that bit of the
cache... though I suspect that's not worth it, even if it is.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/