This latest patch I'm formally announcing has the base O1int changes so far
but includes new semantics for freshly started applications so they can
become interactive very rapidly even during heavy load. This addresses the
"slow to start new apps" evident in O1int so far.
Please test this one and note given just how rapidly things can become
interactive it may have regressions in other settings.
This performs better in all settings than any previous one I've posted in my
testing, but hardware differs substantially!
The latest should always be found:
http://kernel.kolivas.org/2.5
Con
Con,
I have not tested the latest patch from you, but I'm actually running with the one you made public yesterday and it behaves VERY strangely. Sometime, with only XMMS and aMSN (an Instant Messaging app), if I pick an xterm and move it around the screen very fast, xmms stops clearly until I stop doing bad things with the window.
Other times, even when I'm compiling something, I can do that with the windows and XMMS doesn't stop at all.
Very strange, not to?
When I have time, I'll test you patch from today.
Thanks,
--
=============================================================
Luis Miguel Garcia Mancebo
Ingenieria Tecnica en Informatica de Gestion
Universidad de Deusto / University of Deusto
Bilbao / Spain
=============================================================
On Wed, 2 Jul 2003 19:17, Luis Miguel Garcia wrote:
> Con,
>
> I have not tested the latest patch from you, but I'm actually running with
> the one you made public yesterday and it behaves VERY strangely. Sometime,
> with only XMMS and aMSN (an Instant Messaging app), if I pick an xterm and
> move it around the screen very fast, xmms stops clearly until I stop doing
> bad things with the window.
Yes indeed the old one would do that. The time constant was 10 seconds so an
app would have to be running for up to 50 seconds before it was balanced.
This new one fixes that by applying a non linear boost with time.
> Other times, even when I'm compiling something, I can do that with the
> windows and XMMS doesn't stop at all.
After a minute of running xmms I'd say.
> Very strange, not to?
Not at all :)
> When I have time, I'll test you patch from today.
Great.
Con
On Wed, 2 Jul 2003 19:53:59 +1000
Con Kolivas <[email protected]> wrote:
> On Wed, 2 Jul 2003 19:17, Luis Miguel Garcia wrote:
> > Con,
> >
> > I have not tested the latest patch from you, but I'm actually running with
> > the one you made public yesterday and it behaves VERY strangely. Sometime,
> > with only XMMS and aMSN (an Instant Messaging app), if I pick an xterm and
> > move it around the screen very fast, xmms stops clearly until I stop doing
> > bad things with the window.
>
> Yes indeed the old one would do that. The time constant was 10 seconds so an
> app would have to be running for up to 50 seconds before it was balanced.
> This new one fixes that by applying a non linear boost with time.
>
> > Other times, even when I'm compiling something, I can do that with the
> > windows and XMMS doesn't stop at all.
>
> After a minute of running xmms I'd say.
>
> > Very strange, not to?
>
> Not at all :)
Yes, it seems that this explanation is totally ok. I'm going to test newst patch and say you something
Thanks!
Luis Miguel Garcia
Con, must I use granularity with the latest patch? I'm actually compiling with it.
Thanks!
On Wed, 2 Jul 2003 19:53:59 +1000
Con Kolivas <[email protected]> wrote:
> On Wed, 2 Jul 2003 19:17, Luis Miguel Garcia wrote:
> > Con,
> >
> > I have not tested the latest patch from you, but I'm actually running with
> > the one you made public yesterday and it behaves VERY strangely. Sometime,
> > with only XMMS and aMSN (an Instant Messaging app), if I pick an xterm and
> > move it around the screen very fast, xmms stops clearly until I stop doing
> > bad things with the window.
>
> Yes indeed the old one would do that. The time constant was 10 seconds so an
> app would have to be running for up to 50 seconds before it was balanced.
> This new one fixes that by applying a non linear boost with time.
>
> > Other times, even when I'm compiling something, I can do that with the
> > windows and XMMS doesn't stop at all.
>
> After a minute of running xmms I'd say.
>
> > Very strange, not to?
>
> Not at all :)
>
> > When I have time, I'll test you patch from today.
>
> Great.
>
> Con
>
--
=============================================================
Luis Miguel Garcia Mancebo
Ingenieria Tecnica en Informatica de Gestion
Universidad de Deusto / University of Deusto
Bilbao / Spain
=============================================================
On Wed, 2 Jul 2003 20:12, Luis Miguel Garcia wrote:
> Con, must I use granularity with the latest patch? I'm actually compiling
> with it.
No, it is preferable to see if this patch works without it.
Con
On Wednesday 02 July 2003 10:23, Con Kolivas wrote:
> This latest patch I'm formally announcing has the base O1int changes so far
> but includes new semantics for freshly started applications so they can
> become interactive very rapidly even during heavy load. This addresses the
> "slow to start new apps" evident in O1int so far.
>
> Please test this one and note given just how rapidly things can become
> interactive it may have regressions in other settings.
Without this patch, audio skips horribly when I drag a large window. With it,
audio is skipless during window dragging, so I like this patch, whatever it
does (maybe you'd like to do a victory lap and re-explain the theory?). It's
not perfect: in Mozilla, scrolling through a long page with the mouse still
causes skipping.
I'm testing this on a AMD K7 1666 (actual) MHz, 512 MB, VIA VTxxx chipset,
Software is 2.5.73+Gnome+Metacity+ALSA+Zinf. Video hardware is S3 ProSavage
K4M266, running in unaccelerated VGA mode, 1280x1024x16. Yes, I know audio
skips less if video is accelerated, IDE runs in dma, etc, but that's not a
real solution to this soft realtime scheduling problem.
Regards,
Daniel
On Thu, 3 Jul 2003 21:46, Daniel Phillips wrote:
> On Wednesday 02 July 2003 10:23, Con Kolivas wrote:
> > This latest patch I'm formally announcing has the base O1int changes so
> > far but includes new semantics for freshly started applications so they
> > can become interactive very rapidly even during heavy load. This
> > addresses the "slow to start new apps" evident in O1int so far.
> >
> > Please test this one and note given just how rapidly things can become
> > interactive it may have regressions in other settings.
>
> Without this patch, audio skips horribly when I drag a large window. With
> it, audio is skipless during window dragging, so I like this patch,
> whatever it does (maybe you'd like to do a victory lap and re-explain the
Lap complete :) Theory? uh erm it's rather involved but basically instead of
working off the accumulated sleeping ticks gathered in ten seconds it works
on the accumulated sleeping ticks gathered till it wakes up. It has non
linear semantics to cope with the fact that you cant accumulate 10 seconds
worth of ticks (for example) if only 10 seconds has passed (likewise for less
time). Also idle tasks are no longer considered fully interactive but idle
and receive no boost or penalty. Finally they all start with some sleep ticks
inherited by their parent as though they have been running for 1 second at
least.
> theory?). It's not perfect: in Mozilla, scrolling through a long page with
> the mouse still causes skipping.
I have (at least) one more trick up my sleeve which might help this, but this
time I really do want some time to pass and more people test it (in -mm)
before making another change.
Con
On Thursday 03 July 2003 14:21, Con Kolivas wrote:
> Theory? uh erm it's rather involved but basically instead
> of working off the accumulated sleeping ticks gathered in ten seconds it
> works on the accumulated sleeping ticks gathered till it wakes up. It has
> non linear semantics to cope with the fact that you cant accumulate 10
> seconds worth of ticks (for example) if only 10 seconds has passed
> (likewise for less time). Also idle tasks are no longer considered fully
> interactive but idle and receive no boost or penalty. Finally they all
> start with some sleep ticks inherited by their parent as though they have
> been running for 1 second at least.
I'm still pretty much in the dark after that. It says something about your
patch, but it doesn't say much about the problem you're solving, i.e., what's
the Context? (pun intended)
Regards,
Daniel
On Fri, 4 Jul 2003 00:27, Daniel Phillips wrote:
> On Thursday 03 July 2003 14:21, Con Kolivas wrote:
> > Theory? uh erm it's rather involved but basically instead
> > of working off the accumulated sleeping ticks gathered in ten seconds it
> > works on the accumulated sleeping ticks gathered till it wakes up. It has
> > non linear semantics to cope with the fact that you cant accumulate 10
> > seconds worth of ticks (for example) if only 10 seconds has passed
> > (likewise for less time). Also idle tasks are no longer considered fully
> > interactive but idle and receive no boost or penalty. Finally they all
> > start with some sleep ticks inherited by their parent as though they have
> > been running for 1 second at least.
>
> I'm still pretty much in the dark after that. It says something about your
> patch, but it doesn't say much about the problem you're solving, i.e.,
> what's the Context? (pun intended)
Basically? Who gets to preempt who and for how long. The interactivity
estimator should decide that the correct task is interactive and get a
dynamically higher priority and larger timeslice. Is this what you're asking?
Con
On Thursday 03 July 2003 16:34, Con Kolivas wrote:
> On Fri, 4 Jul 2003 00:27, Daniel Phillips wrote:
> > I'm still pretty much in the dark after that. It says something about
> > your patch, but it doesn't say much about the problem you're solving,
> > i.e., what's the Context? (pun intended)
>
> Basically? Who gets to preempt who and for how long. The interactivity
> estimator should decide that the correct task is interactive and get a
> dynamically higher priority and larger timeslice. Is this what you're
> asking?
I guess what I'm saying is, the problem is far from solved, however your
concrete results demonstrate you've got an intuitive grasp of how to go at
it. I'd like to dig in and find out what the deep issues are. As I've
basically ignored scheduling up to now, including all of the details of
Ingo's work, there's some background to fill in. Being lazy, I'd prefer to
read somebody's detailed [rfc] instead of going through the process of
reverse engineering it myself. I presume I'm not the only one.
Regards,
Daniel