static int's for proc_change_penalty and tlb_flush_penalty

[James Manning]

[ Thursday, January 20, 2000 ] Mike Karmyshev wrote:
> James Manning wrote:
> > I was thinking about making the penalties in goodness() for processor
> > change and TLB flushes into static int's and putting them into /proc
> 
> Oops,I've already done it for testing purposes three or maybe four months
> ago,when I had an Abit BP6 motherboard at home. Moved CPU change penalty
> from constant to sysctl to be able to change it on the fly.It seems to me
> that changing PENALTY value doesn't affect SMP performance too much.The
> difference was less than 2% on PVMPovray benchmark.

Just out of curiosity, what was the number of active run-queue processes
in relation to the number of processors? What range of penalties did
you try?

My logic is that on a quad-CPU machine (just as an example), a single
process, esp. for larger L1/L2 caches, would do better to be penalized
heavier for processor migration, whereas a dual celery BP6 (sound
familiar? :) with 128K full-speed L2's would be less sensitive to this
move as the small, fast cache will warm up much more quickly.  In this
light, I'd imagine the penalty change to *not* make a large difference
on that BP6 you tested it on, but on 4- and 8-way's with 2MB to 8MB of
L2's it could be a significant gain to have this be settable.

It's also possible that on 8-way x86 machines the penalty increase could
help keep the process on the same side of the Profusion chipset helping
lighten its cache-coherency load and possibly cutting down the DEFER and
LOCK's showing up on the buses.

These are just theories, though, and coming up with realistic loads
with parasitic enough cache behavior to show a real performance difference
may indeed be difficult.  We'll see :)  The TLB flush penalty is a
whole other issue, but it seems agreed that the "1" factor it has
so far (increasing to 5 if Andrea takes that tiny patch I sent) is
smallish.

If you still have this patch of code around, could you post it or mail
it over?  I'd love to not reinvent this wheel :)

James
-- 
Miscellaneous Engineer --- IBM Netfinity Performance Development

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