lkml.org 
[lkml]   [2003]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC] Re: Blender profiling-1 O16.2int
Date
I've investigated this starvation issue now that I've been given a testcase. 
First some background. Mats reported that he could elicit starvation in
blender so I downloaded that and have been thrashing it out trying to find
out what happens. Here are relevant excerpts from the discussion.

On Sun, 17 Aug 2003 15:38, Voluspa wrote:
> Ah, the freezes has been there with all 2.6s, just shorter (1/2 - 2
> seconds). Where I didn't see them was in the older blender version of
> 2.23. I'll investigate it more thorough.

This struck me as interesting because the starvation was there in the vanilla
scheduler anyway, but for a shorter period. Even more interesting was the
suggestion that it didn't happen with previous versions of blender.

Reproducing it was:

> Voluspa <voluspa@comhem.se> wrote:
>Thusly: Start program, move mouse to get rid of splash screen. Click and
>hold down 3rd mouse button (unless you use simulate 3 buttons in X, then
>it's left-right-mousebutton simultaniously) anywhere on the white grid
>(first view is top-down) and move mouse around... That is how you rotate
>the world plane around an axes. Doing this quickly, or slowly for a
>longer period, I freeze.

Which I tried for some time and eventually managed to get locally. In the
meantime,

> Voluspa <voluspa@comhem.se> wrote:
> But not in 2.23, not even with this O16.2! Don't see any freezes with
> that older Blender version.

So I had my suspicions about what was happening already based on that
information. Anyway I ran top in batch mode, reproduced the starvation and
got this (just X and 3[blender] at one second intervals):

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command
782 root 16 0 109m 39m 77m R 80.5 7.9 2:37.17 X
12553 con 15 0 12648 6252 9072 S 19.9 1.2 0:07.98 3

782 root 16 0 109m 39m 77m R 73.6 7.9 2:37.91 X
12553 con 15 0 12648 6252 9072 R 23.9 1.2 0:08.22 3

782 root 16 0 109m 39m 77m R 79.5 7.9 2:38.71 X
12553 con 15 0 12648 6252 9072 S 20.9 1.2 0:08.43 3

Starvation starts here:
782 root 16 0 109m 39m 77m R 95.4 7.9 2:39.67 X
12553 con 15 0 12648 6252 9072 S 3.0 1.2 0:08.46 3

12553 con 16 0 12648 6252 9072 R 73.6 1.2 0:09.20 3
782 root 17 0 109m 39m 77m R 25.8 7.9 2:39.93 X

12553 con 16 0 12648 6252 9072 R 98.4 1.2 0:10.19 3
782 root 17 0 109m 39m 77m R 0.0 7.9 2:39.93 X

12553 con 16 0 12648 6252 9072 R 99.4 1.2 0:11.19 3
782 root 17 0 109m 39m 77m R 0.0 7.9 2:39.93 X

12553 con 16 0 12648 6252 9072 R 99.4 1.2 0:12.19 3
782 root 17 0 109m 39m 77m R 0.0 7.9 2:39.93 X

12553 con 16 0 12648 6252 9072 R 99.9 1.2 0:13.20 3
782 root 17 0 109m 39m 77m R 0.0 7.9 2:39.93 X

[snip some more seconds]
and ends here:
12553 con 15 0 12648 6252 9072 S 39.8 1.2 0:23.59 3
782 root 16 0 109m 39m 77m S 16.9 7.9 2:40.10 X

782 root 15 0 109m 39m 77m S 8.9 7.9 2:40.19 X
12553 con 15 0 12964 6576 9072 S 2.0 1.3 0:23.61 3

Now for those that can't see what this is, blender and X are interactive tasks
and getting high priority (PRI < 18) which makes sense. During heavy usage of
blender, it is X that gets pegged for cpu usage (ie it is doing the work for
blender), and eventually it gets expired onto the expired array for being
naughty and stops doing anything till all other tasks have finished working
on the active array. Now normally, blender should just sleep and wait till X
comes alive again before it does anything. However here it shows clearly that
it is spinning madly looking for something from X, and poor X can't do
anything. This is the busy on wait I've described. Meanwhile, since blender
was seen as an interactive task (which it is), it preempts everything lower
priority than it till it also gets booted.

Now in O16.2 I managed to minimise this happening by not allowing tasks to
preempt their waker, but this has no effect if X gets expired. The evidence I
really needed was that this also happened to the vanilla scheduler to a
lesser degree and that it is a software flaw. This same thing happens to
2.6.0-test3 for 1-2 seconds, and doesn't happen at all with a previous
version of blender.

So where does this leave us?

Well first I can remove entirely the not preempting the waker in O16s since
that is faulty for smp, and doesn't really fix the problem.

Second, any applications that exhibit this should be fixed since it is a bug.

Finally I still need to find a way to prevent this from transiently starving
the system without undoing the interactive improvements to normal
applications; I certainly don't intend to make them "work nicely" just for
the sake of it.

I do have some ideas about how to progress with this (some Mike has suggested
to me previously), but so far most of them involve some detriment to the
interactive performance on other apps. So I'm appealing to others for ideas.

Comments?

Con

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

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.065 / U:3.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site