Re: static int's for proc_change_penalty and tlb_flush_penalty

From: Mike Karmyshev (mike@katren.ru)
Date: Thu Jan 20 2000 - 22:06:14 EST


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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:24 EST