2.6: More about interactivity

2.6: More about interactivity

[Felipe Alfaro Solana]

Just wanted to throw a few thoughts I have about the current scheduler
and my experiences with it (well, with my specific workloads and
applications on my little 700 Mhz PIII laptop).

I feel that 2.6.0-test2-mm5 is not as smooth as 2.6.0-test2-mm2 (O10int)
was. I am experiencing sound skips, but this time I'm not using XMMS,
but Juk, a KDE player which uses the aRTS sound daemon, which in turn, I
assume it uses the OSS API.

With X reniced at +0, the system feels not as smooth as 2.6.0-test2-mm2,
but at least there are no sound skips. However, to gain on smoothness, I
have chosen to renice X to -20. Renicing X to -20 makes Juk skip like
crazy simply by dragging a window over the screen. Also, with X at -20,
opening a long Bookmarks Konqueror menu also causes sound skips (even
with XMMS). By now, I'm sticking at +0, but I really miss those times
when I was running O10int and the desktop was as smooth as silk.

Now, let's go on talking about plain 2.6.0-test2-bk6. I feel it not as
good as Con's scheduler and, when starting a CPU hoggers, I can feel how
the system lags (starves) considerably for a few seconds. For example,
when launching an absurd while loop (while true; do a=2; done), X stops
responding for nearly 1 second, then becomes responsive but laggy for
another one, and then starts acting normally.

When O10int was released, I knew and felt the scheduler was working
great for me (well, it worked great with my workload and applications),
but now I'm starting to get afraid that, for me, it's getting again up
to a point like in the past when I was forced to continuously tweak
every kernel knob to try to make it smoother and make it fit my
particular needs.

Is there any pending work on the scheduler that I don't know of, or are
we getting past a point-of-no-return, where the scheduler will be left
as it is right now? I'm saying this as it is a long time since I haven't
heard any notice about new developments on the subject from either Con
or Ingo...

Greetings from a worried scheduler tester.

Re: 2.6: More about interactivity

[Roger Larsson]

On Thursday 07 August 2003 20.15, Felipe Alfaro Solana wrote:
> Just wanted to throw a few thoughts I have about the current scheduler
> and my experiences with it (well, with my specific workloads and
> applications on my little 700 Mhz PIII laptop).
>
> I feel that 2.6.0-test2-mm5 is not as smooth as 2.6.0-test2-mm2 (O10int)
> was. I am experiencing sound skips, but this time I'm not using XMMS,
> but Juk, a KDE player which uses the aRTS sound daemon, which in turn, I
> assume it uses the OSS API.

Arts uses whatever you have - i think ALSA is preferred.

>
> With X reniced at +0, the system feels not as smooth as 2.6.0-test2-mm2,
> but at least there are no sound skips. However, to gain on smoothness, I
> have chosen to renice X to -20. Renicing X to -20 makes Juk skip like
> crazy simply by dragging a window over the screen. Also, with X at -20,
> opening a long Bookmarks Konqueror menu also causes sound skips (even
> with XMMS). By now, I'm sticking at +0, but I really miss those times
> when I was running O10int and the desktop was as smooth as silk.

Wait a minute!

Arts (I think JuK only tells Arts what to play) is a realtime task - if it 
does not meet its deadline you get drop outs. X is not a realtime task 
(unless you display video using it - is X even involved in video/3D?).

But you run X at a higher priority than Arts!? Don't you? You have told the
scheduler that X is more important than Arts - and you are surpriced that
you get dropouts?

Arts should really run as SCHED_FIFO or SCHED_RR but that opens another
can of worms - audio plugins can busy lock the computer... We need 
SCHED_SOFTRR now!

But you can try to prioritize arts higher than X (arts at -20, X at -15).
Or set suid root on artswrapper to get SCHED_FIFO, and then enable realtime 
scheduling in configuration.

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden

Re: 2.6: More about interactivity

[Con Kolivas]

On Fri, 8 Aug 2003 04:15, Felipe Alfaro Solana wrote:
> Just wanted to throw a few thoughts I have about the current scheduler
> and my experiences with it (well, with my specific workloads and
> applications on my little 700 Mhz PIII laptop).
>
> I feel that 2.6.0-test2-mm5 is not as smooth as 2.6.0-test2-mm2 (O10int)
> was. I am experiencing sound skips, but this time I'm not using XMMS,
> but Juk, a KDE player which uses the aRTS sound daemon, which in turn, I
> assume it uses the OSS API.
>
> With X reniced at +0, the system feels not as smooth as 2.6.0-test2-mm2,
> but at least there are no sound skips. However, to gain on smoothness, I
> have chosen to renice X to -20. Renicing X to -20 makes Juk skip like
> crazy simply by dragging a window over the screen. Also, with X at -20,
> opening a long Bookmarks Konqueror menu also causes sound skips (even
> with XMMS). By now, I'm sticking at +0, but I really miss those times
> when I was running O10int and the desktop was as smooth as silk.
>
> Now, let's go on talking about plain 2.6.0-test2-bk6. I feel it not as
> good as Con's scheduler and, when starting a CPU hoggers, I can feel how
> the system lags (starves) considerably for a few seconds. For example,
> when launching an absurd while loop (while true; do a=2; done), X stops
> responding for nearly 1 second, then becomes responsive but laggy for
> another one, and then starts acting normally.
>
> When O10int was released, I knew and felt the scheduler was working
> great for me (well, it worked great with my workload and applications),
> but now I'm starting to get afraid that, for me, it's getting again up
> to a point like in the past when I was forced to continuously tweak
> every kernel knob to try to make it smoother and make it fit my
> particular needs.
>
> Is there any pending work on the scheduler that I don't know of, or are
> we getting past a point-of-no-return, where the scheduler will be left
> as it is right now? I'm saying this as it is a long time since I haven't
> heard any notice about new developments on the subject from either Con
> or Ingo...

It's ok I'm not dead. It is true I'm having to rethink some of my work to 
bring some aspects of the interactive performance back up to O10 with Ingo's 
changes. The changes since his patch have gone in have addressed other issues 
but I'm trying to get it back to O10 standard in your issues. Just keep 
testing when I throw patches at you and remember I have an unrelated day job 
and family so the weekend is kinda good for development.

Con

Re: 2.6: More about interactivity

[Szonyi Calin]

Felipe Alfaro Solana said:
>
> With X reniced at +0, the system feels not as smooth as 2.6.0-test2-mm2,
> but at least there are no sound skips. However, to gain on smoothness, I
> have chosen to renice X to -20. Renicing X to -20 makes Juk skip like
> crazy simply by dragging a window over the screen. Also, with X at -20,
> opening a long Bookmarks Konqueror menu also causes sound skips (even
> with XMMS). By now, I'm sticking at +0, but I really miss those times
> when I was running O10int and the desktop was as smooth as silk.
>

Some comments:
Renicing X at -20 is silly. It is normal that xmms skips when
X is reniced because X gets the cpu time not xmms.
Also a normal user doesn't have access to nice values below
zero, so the scheduler should work for normal systems not
for those in which process foo is reniced at -bar priority.

Calin

-- 
# fortune
fortune: write error on /dev/null --- please empty the bit bucket


-----------------------------------------
This email was sent using SquirrelMail.
   "Webmail for nuts!"
http://squirrelmail.org/

Re: 2.6: More about interactivity

[Felipe Alfaro Solana]

On Fri, 2003-08-08 at 17:20, Szonyi Calin wrote:

> Some comments:
> Renicing X at -20 is silly. It is normal that xmms skips when
> X is reniced because X gets the cpu time not xmms.

I didn't say XMMS skips when X is reniced at -20 :-)
It's Juk the one that skips and, as one LKLM reader said, it has to do
with the fact that aRTS had less priority than X.

> Also a normal user doesn't have access to nice values below
> zero, so the scheduler should work for normal systems not
> for those in which process foo is reniced at -bar priority.

Can't follow you reasoning. I think the scheduler should work for any
priority, either negative (the most) or possitive (the least). In fact,
some kernel threads are reniced negatively since they need full
priority.