On Sunday 22 April 2007 23:07, Willy Tarreau wrote:
> On Sun, Apr 22, 2007 at 10:18:32PM +1000, Con Kolivas wrote:
> > On Sunday 22 April 2007 21:42, Con Kolivas wrote:
> >
> > Willy I'm still investigating the idle time and fluctuating load as a
> > separate issue.
>
> OK.
>
> > Is it possible the multiple ocbench processes are naturally
> > synchronising and desynchronising and choosing to sleep and/or run at the
> > same time?
>
> I don't think so. They're independant processes, and I insist on reducing
> their X work in order to ensure they don't get perturbated by external
> factor. Their work consist in looping 250 ms and waiting 750 ms, then
> displaying a new progress line.
Well if they always wait 750ms and they always do 250ms of work, they will
never actually get their 250ms in a continuous stream, and may be waiting on
a runqueue while working. What I mean then is that scheduling could cause
that synchronising and desynchronising unwittingly by fluctuating the
absolute time over which they get their 250ms. The sleep always takes 750ms,
but the actual physical time over which they get their 250ms fluctuates by
scheduling aliasing. If instead the code said "500ms has passed while I only
did 250ms work so I should sleep for 250ms less" this aliasing would go away.
Of course this is impossible since a fully loaded machine would mean each
process should never sleep. I'm not arguing this is correct behaviour for the
scheduler to cause this, mind you, nor am I saying it's wrong behaviour. I'm
just trying to understand better how it happens and what (if anything) should
be done about it. Overall their progress and cpu distribution appears
identical, as you said. The difference is that the CFS design intrinsically
manages this exact scenario by design with its sleep/run timing mechanism.
> > I can remove the idle time entirely by running ocbench at nice 19
> > which means they are all forced to run at basically the same time by the
> > scheduler.
>
> It may indicate some special handling of nice ?
By running them nice 19 the scheduler has effectively just sequentially
schedules them, and there is no aliasing.
--
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
