From: Russ Weight <rweight@us.ibm.com>
To: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: mingo@elte.hu, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Scalable CPU bitmasks
Date: Wed, 20 Mar 2002 15:04:42 -0800 [thread overview]
Message-ID: <20020320150442.A1264@us.ibm.com> (raw)
In-Reply-To: <20020318140700.A4635@us.ibm.com> <200203190728.g2J7Srq31344@Port.imtp.ilyichevsk.odessa.ua>
On Tue, Mar 19, 2002 at 09:28:25AM -0200, Denis Vlasenko wrote:
> On 18 March 2002 20:07, Russ Weight wrote:
> > While systems with more than 32 processors are still
> > out in the future, these interfaces provide a path for gradual
> > code migration. One of the primary goals is to provide current
> > functionality without affecting performance.
>
> Not so far in the future. "7.52 second kernel compile" thread is about
> timing kernel compile on the 32 CPU SMP box.
>
> I don't know whether BUG() in inlines makes them too big, but
> _for() _loops_ in inline functions definitely do that.
> Here's one of the overgrown inlines:
I was hoping for some feedback regarding the use of BUG(). I have
been experimenting with the patch - changing various bitmasks to
use this new datatype. None of them do the error checking that I am
adding. Is it worth the overhead to have these checks at all? If
they ever trigger, they are indicative of an error elsewhere in the
kernel...
With respect to the for loops: For CPUMAP_SIZE > 1, most of the
interfaces expand to a "for loop". This is a performance vs. bloat
tradeoff. The "for-loop" versions of the functions _could_ be moved
to a cpumap.c file under lib. Is this the recommended approach?
The cpumap_format() function below is probably the worst offender.
There is no real performance value in making it an inline function...
>
> > +static inline char *cpumap_format(cpumap_t map, char *buf, int size)
> > +{
> > + if (size < CPUMAP_BUFSIZE) {
> > + BUG();
> > + }
> > +
> > +#if CPUMAP_SIZE > 1
> > + sprintf(buf, "0x" CPUMAP_FORMAT_STR, map[CPUMAP_SIZE-1]);
> > + {
> > + int i;
> > + char *p = buf + strlen(buf);
> > + for (i = CPUMAP_SIZE-2; i >= 0; i--, p += (sizeof(long) + 1)) {
> > + sprintf(p, " " CPUMAP_FORMAT_STR, map[i]);
> > + }
> > + }
> > +#else
> > + sprintf(buf, "0x" CPUMAP_FORMAT_STR, map[0]);
> > +#endif
> > + return(buf);
> > +}
> --
> vda
--
Russ Weight (rweight@us.ibm.com)
Linux Technology Center
next prev parent reply other threads:[~2002-03-20 23:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-18 22:07 [PATCH] Scalable CPU bitmasks Russ Weight
2002-03-19 11:28 ` Denis Vlasenko
2002-03-19 7:56 ` Andrew Morton
2002-03-20 23:04 ` Russ Weight [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-03-18 22:28 Manfred Spraul
2002-03-18 22:42 ` Tim Hockin
2002-03-18 22:44 ` Russ Weight
2002-01-30 0:32 Russ Weight
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=20020320150442.A1264@us.ibm.com \
--to=rweight@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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.