static int's for proc_change_penalty and tlb_flush_penalty

[Mike Karmyshev]

James Manning wrote:
> 
> [ 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?
I've tried 2-200 processes range on my dual Celeron box and  0-1000
penalty range.
> 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.
Uhm... Unfortunately,I don't have any of those 8way Zeon boxes at home
:)
> 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.
My opinion is that probaly penalty value should change depending on
loadavg dynamically...Possible? Usable? :)
> 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 :)
Ok,I'll post it when I'll be at home.
> James
-- 
	WBR,Mike

-
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/