Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] 2.5.21 Nonlinear CPU support | Date | Wed, 12 Jun 2002 16:58:23 +1000 |
| |
In message <20020611.021043.04190747.davem@redhat.com> you write: > From: Rusty Russell <rusty@rustcorp.com.au> > Date: Tue, 11 Jun 2002 19:09:44 +1000 > > In message <3D05A9E8.FF0DA223@zip.com.au> you write: > > and slowdown: > > ARGH! STOP IT! I realize it's 'leet to be continually worrying about > possible microoptimizations, but I challenge you to *measure* the > slowdown between: > > Regardless, his space arguments still hold.
You can allocate based on cpu_possible(cpu) (which is in the next patch) if you like, but I think you're better off fixing the existing NR_CPUS bloat as well, and keeping all the code simple.
> I don't like having everyone eat the overhead that hotplugging cpus > seem to entail.
But there's an important difference between something which is simple and unoptimized, and something which is unoptimizable.
> And remember, it's the anal "every microoptimization at all costs" > people that keep the kernel sane and from running out of control bloat > wise.
But it also gave us crap like net/ipv4/route.c:ip_rt_acct_read() 8(
I know *you* benchmark and read the asm during optimization, but it's quite clear that others are so scared of "bloat" criticism that they optimize without measuring the straightforward case *first*.
Remember, to be cool: 1) Use bitops and memory barriers not spinlocks, 2) Use inlines everywhere, 3) Use likely()/unlikely() on every branch 4) Use prefetch() everywhere, 5) Use gotos to minimize the path length 6) __set_current_state() not set_current_state() 7) Pass in current as a function param
Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
| |