Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [PATCH] 2.6.0 batch scheduling, HT aware | Date | Wed, 24 Dec 2003 09:09:18 +1100 |
| |
On Wed, 24 Dec 2003 02:51, bill davidsen wrote: > There are two goals here. Not having a batch process on one siling makes > sense, and I'm going to try Con's patch after I try Nick's latest. > Actually, if they play nicely I would use both, batch would be very > useful for nightly report generation on servers.
No hope of them playing nicely, but at some later stage I might resync on top of Nick's work if I like the direction it takes (which looks likely!)
> But WRT the whole HT scheduling, it would seem that ideally you want to > schedule the two (or N) processes which have the lowest aggregate cache > thrash, if you had a way to determine that. I suspect that a process > which had a small itterative inner loop with a code+data footprint of > 2-3k would coexist well with almost anything else. Minimizing the FPU > contention also would improve performance, no doubt. I don't know that > there are the tools at the moment to get this information, but it seems > as though until it's available any scheduling will be working in the > dark to some extent.
Impossible with current tools. Only userspace would have a chance of predicting this and the simple rule we work off is that userspace can't be trusted so this does not appear doable in the foreseeable future.
> Feel free to tell me I misread this problem.
> I my experience, on servers it's more important to avoid really bad > behaviour all of the time than to have perfect behaviour most of the > time. All of the recent scheduler work from Nick, Con and Ingo has > avoided "jackpot cases" quite well, for which I thank you and encourage > you to continue. If server response goes from 20ms to 100ms Saturday > night, we discuss it at a status meeting Monday morning and make > suggestions to management. If response goes to 2sec we discuss it with > management at 2am and they make suggestions :-( > > So far 2.6.0 has been quite good at "bend but do not break" under load. > Great job!
Excellent! I'm sure we'll hear from you when you turn the knob up to 11/10.
Con
- 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/
| |