On Mon, 11 Aug 2003 19:15, Nick Piggin wrote:
Con Kolivas wrote:
On Mon, 11 Aug 2003 15:44, Martin Schlemmer wrote:Yeah make -j10s won't be without impact, but I think for a lot of
On Sat, 2003-08-09 at 11:04, Con Kolivas wrote:A UP HT box you mean? That shouldn't be capable of running multiple make
On Sat, 9 Aug 2003 01:49, Con Kolivas wrote:Not to be nasty or such, but all these patches have taken
More duck tape interactivity tweakss/duck/duct
Wli pointed out an error in the nanosecond to jiffy conversion whichLooks like I broke SMP build with this. Will fix soon; don't bother
may have been causing too easy to migrate tasks on smp (? performance
change).
trying this on SMP yet.
a very responsive HT box to one that have issues with multiple
make -j10's running and random jerkyness.
-j10s without some noticable effect. Apart from looking impressive, there
is no point in having 30 cpu heavy things running with only 1 and a bit
processor and the machine being smooth as silk; the cpu heavy things will
just be unfairly starved in the interest of appearance (I can do that
easily enough). Please give details if there is a specific issue you
think I've broken or else I wont know about it.
interactive stuff they don't need a lot of CPU, just to get it
in a timely manner. And Martin did say it had been responsive.
Sounds like in this case your changes are causing the interactive
stuff to get less CPU or higher scheduling latency?
Sigh..,
No, it sounds to me like things are expiring faster than on default. He didn't say make -j10, it was multiple -j10s. This is one where you simply cannot let the scheduler keep starving the make -j10s indefinitely for X; on a server or multiuser box X will simply cause unfair starvation. I'm trying to find a workaround for this without rewriting whole sections of the scheduler code, but I'm just not sure I should be trying to optimise for a desktop that runs loads >16 per cpu. (I'll keep trying though, but if there is no workaround that remains fair it wont happen)