Messages in this thread |  | | | Date | Mon, 07 Nov 2005 17:58:16 -0800 | | From | "Martin J. Bligh" <> | | Subject | Re: Database regression due to scheduler changes ? |
| |
>>> Im also considering adding balance on fork for ppc64, it seems like a >>> lot of people like to run stream like benchmarks and Im getting tired of >>> telling them to lock their threads down to cpus. >> >> Please don't screw up everything else just for stream. It's a silly >> frigging benchmark. There's very little real-world stuff that really >> needs balance on fork, as opposed to balance on clone, and it'll slow >> down everything else. > > Long lived and memory intensive cloned or forked tasks will often > [but far from always :(] want to be put on another memory controller > from their siblings. > > On workloads where there are lots of short lived ones (some bloated > java programs), the load balancer should normally detect this and > cut the balance-on-fork/clone. > > Of course there are going to be cases where this fails. I haven't > seen significant slowdowns in tests, although I'm sure there would > be some at least small regressions. Have you seen any? Do you have > any tests in mind that might show a problem?
Anything fork/exec-y should show it's slower. Most stuff either forks and execs (in case it's silly to do it twice, and much cheaper to do it at exec time), or it's a clone, in which case a different set of rules applies for what you want (and actually, I suspect fork w/o exec is much the same).
Of course the pig is you can't determine at fork whether it'll exec or not, so you optimise for the common case, which is "do exec", unless given a hint otherwise.
For clone, and I suspect fork w/o exec, you have a tightly coupled group of processes that really would like to be close to each other. If you have 1 app on the whole system, you *may* want it spread across the system. If you have nr_apps >= nr_nodes, you probably want them node local. Determining which workload you have is messy, and may change.
Tweak the freak benchmark, not everything else ;-)
M.
- 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/
|  |