From: William Lee Irwin III <wli@holomorphy.com>
To: Keith Owens <kaos@ocs.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: cpu-2.5.64-1
Date: Sun, 16 Mar 2003 03:32:54 -0800 [thread overview]
Message-ID: <20030316113254.GH20188@holomorphy.com> (raw)
In-Reply-To: <17275.1047813144@ocs3.intra.ocs.com.au>
On Sun, 16 Mar 2003 02:10:55 -0800, William Lee Irwin III wrote:
>> Hmm. It shouldn't make a difference with respect to optimizing them.
>> My API passes transparently by reference:
>> #define cpu_isset(cpu, map) test_bit(cpu, (map).mask)
On Sun, Mar 16, 2003 at 10:12:24PM +1100, Keith Owens wrote:
> Some of the 64 bit archs implement test_bit() as taking int * instead
> of long *. That generates unoptimized code for the case of NR_CPUS <
> 64.
> #if NR_CPUS < 64
> #define cpu_isset(cpu, map) (map.mask & (1UL << (cpu)))
> ...
> generates better code on those architectures. Yet another special case :(
NUMA-Q is 32-bit so maybe there's more to be done, but never mind that.
But in general, what else can I do for you here? IIRC the MIPS tree is
still stuck around 2.5.47, and I've got little or no idea about the
status of larger MIPS boxen in 2.4.x and much less of one for 2.5.x.
I might need a little more to go on.
One of the major sticking points I appear to have developed here is
that I need to go around sweeping arch code for this stuff, but I don't
have the boxen and can barely build the trees (if at all) for non-x86.
What's the state of 2.5.x on the big machines where you're at?
Another thought I had was wrapping things in structures for both small
and large, even UP systems so proper typechecking is enforced at all
times. That would probably need a great deal of arch sweeping to do,
especially as a number of arches are UP-only (non-SMP case's motive #2).
I'm glad that _someone_ is talking, the lack of feedback on this has
been a bit depressing, especially given its "we needed this 5 years ago"
(from multiple vendors/arches) nature and general triviality.
-- wli
next prev parent reply other threads:[~2003-03-16 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-11 4:24 cpu-2.5.64-1 William Lee Irwin III
2003-03-11 7:17 ` cpu-2.5.64-1 Zwane Mwaikambo
2003-03-11 8:25 ` cpu-2.5.64-1 Zwane Mwaikambo
2003-03-16 7:39 ` cpu-2.5.64-1 Keith Owens
2003-03-16 8:36 ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 9:19 ` cpu-2.5.64-1 Keith Owens
2003-03-16 9:46 ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 10:10 ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 11:12 ` cpu-2.5.64-1 Keith Owens
2003-03-16 11:32 ` William Lee Irwin III [this message]
2003-03-16 11:53 ` cpu-2.5.64-1 Keith Owens
2003-03-16 12:00 ` cpu-2.5.64-1 William Lee Irwin III
2003-03-16 12:42 ` cpu-2.5.64-1 Horst von Brand
2003-03-16 19:14 ` cpu-2.5.64-1 William Lee Irwin III
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=20030316113254.GH20188@holomorphy.com \
--to=wli@holomorphy.com \
--cc=kaos@ocs.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox