Re: Poor PostgreSQL scaling on Linux 2.6.25-rc5 (vs 2.6.22)

[Nick Piggin]

On Monday 17 March 2008 16:21, Willy Tarreau wrote:
> On Sun, Mar 16, 2008 at 10:16:36PM -0700, Ray Lee wrote:
> > On Sun, Mar 16, 2008 at 5:44 PM, Nick Piggin <nickpiggin@xxxxxxxxxxxx> 
> > > Can this be changed by default, please?
> >
> > Not without benchmarks of interactivity, please. There are far, far
> > more linux desktops than there are servers. People expect to have to
> > tune servers (I do, for the servers I maintain). People don't expect
> > to have to tune a desktop to make it run well.
>
> Oh and even on servers, when your anti-virus proxy reaches a load of 800,
> you're happy no to have too large a time-slice so that you regularly get
> a chance of being allowed to type in commands over SSH.

Your ssh session should be allowed to run anyway. I don't see the difference.
If the runqueue length is 100 and the time-slice is (say) 10ms, then if your
ssh only needs average of 5ms of CPU time per second, then it should be run
next when it becomes runnable. If it wants 20ms of CPU time per second, then
it has to wait for 2 seconds anyway to be run next, regardless of whether
the timeslice was 10ms or 20ms.


> Large time-slices are needed only in HPC environments IMHO, where only
> one task runs.

That's silly. By definition if there is only one task running, you don't
care what the timeslice is.

We actually did conduct some benchmarks, and a 10ms timeslice can start
hurting even things like kbuild quite a bit.

But anyway, I don't care what the time slice is so much (although it should
be higher -- if the scheduler can't get good interactive behaviour with a
20-30ms timeslice in most cases then it's no good IMO). I care mostly that
the timeslice does not decrease when load increases.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/