From: Andi Kleen <ak@muc.de>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Cc: Ashok Raj <ashok.raj@intel.com>, Andrew Morton <akpm@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch 13/14] x86_64: Use common functions in cluster and physflat mode
Date: 12 Sep 2005 01:02:20 +0200
Date: Mon, 12 Sep 2005 01:02:20 +0200 [thread overview]
Message-ID: <20050911230220.GA73228@muc.de> (raw)
In-Reply-To: <Pine.LNX.4.61.0509091439110.978@montezuma.fsmlabs.com>
On Sun, Sep 11, 2005 at 09:44:16AM -0700, Zwane Mwaikambo wrote:
> On Fri, 9 Sep 2005, Ashok Raj wrote:
>
> > In general we need
> >
> > flat_mode - #cpus <= 8 (Hotplug defined or not, so we use mask version
> > for safety)
> >
> > physflat or cluster_mode when #cpus >8.
>
> I agree there.
>
> > If we choose physflat as default for #cpus <=8 (with hotplug) would make
> > IPI performance worse, since it would do one cpu at a time, and requires 2
> > writes per cpu for each IPI v.s just 2 for a flat mode mask version of the API.
>
> I don't see the benefit then :/ I certainly hope we don't go that route.
I originally made that objection, but Ashok then did some benchmarks
that showed essentially no difference. I can see the point - it's
likely that an access to the local APIC (which is in the CPU) is fast
(we know it is) and all the time is dominated by sending the
requests over the wires between the CPUs. So it shouldn't matter
much if you use sequence mode or masks.
That is why I changed my mind and just made physflat default for the hotplug
case (which will be essentially everywhere because I expect most kernels
to have hotplug enabled in the future)
It's a bit of a mess in mm right now because me and Ashok have been fixing
similar problems in a different way (e.g. the patch in flat to
use the sequence sending path is also not needed anymore with that)
Need to clean this up a bit.
Handling it properly for i386 is also still needed e.g. the older physflat
patch I did needs to be merged with bigsmp and cleaned up a bit.
But I don't have time to do it before monday so it'll miss the 2.6.14
window anyways.
-Andi
next prev parent reply other threads:[~2005-09-11 23:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200509032135.j83LZ8gX020554@shell0.pdx.osdl.net>
[not found] ` <20050905231628.GA16476@muc.de>
2005-09-06 23:12 ` [patch 13/14] x86_64: Use common functions in cluster and physflat mode Ashok Raj
2005-09-09 17:07 ` Zwane Mwaikambo
2005-09-09 20:45 ` Ashok Raj
2005-09-11 16:44 ` Zwane Mwaikambo
2005-09-11 23:02 ` Andi Kleen [this message]
2005-09-12 22:23 ` Ashok Raj
2005-09-13 8:10 ` Andi Kleen
2005-09-13 14:53 ` Zwane Mwaikambo
2005-09-13 15:31 ` Andi Kleen
2005-09-10 0:30 ` Andi Kleen
2005-09-10 1:51 ` Zwane Mwaikambo
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=20050911230220.GA73228@muc.de \
--to=ak@muc.de \
--cc=akpm@osdl.org \
--cc=ashok.raj@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zwane@arm.linux.org.uk \
/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.