Messages in this thread | | | Date | Fri, 21 Jan 2000 09:06:14 +0600 | From | Mike Karmyshev <> | Subject | Re: static int's for proc_change_penalty and tlb_flush_penalty |
| |
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/
| |