Re: "REPORT: sd-0.46 vs cfs-v6 vs mainline 2.6.21-rc7 Beryl + Video + Audio"

[hechacker1]

> so SD context-switched twice as much and saturated the CPU fully, while
> under cfs-v6 there was 34% idle time left. That double context-switch
> rate and higher CPU utilization could easily result in you experiencing
> a 'smoother' desktop (and smoother video playback) on SD.
>
> could you try to maximize the preemption ratio on CFS by using a
> sched_granularity_ns of 0? Does that result in a higher context-switch
> rate and in better CPU utilization? Thanks,
>
>     Ingo

Thanks for pointing out the idle cpu usage. I hadn't noticed it before.

I re-ran the tests with sched_granularity_ns 0, but fyi, I did try
that, as well as many
values around 5000000, 1-10ms, and some huge values too just to see
how the scheduler reacted. The reason why I settled on 2000000 was
because of trial and error and determining that value produced the
best fps.

Large values than 5000000 clearly caused the FPS to drop. Too small
values did the same.

FYI, when the desktop is sitting on only one cube side, i.e. normal
desktop. The idle usage for cfs and SD goes down to nearly 0.

But when the cube is in between faces in free form mode (the mouse
controls the cube in 3D space) the idle cpu usage goes up, for both
cfs, SD, and mainline.

I looked carefully at the idle usage values for cfs-v6 and sd-0.46, and
cfs hovers around ~35% idle cpu, sd hovers around ~3-30%, usually ~15% overall.

So perhaps my video card is fill rate limited during this stress
test... but... mplayer and totem are visibly refreshing faster with
sd-0.46, almost watchable and smooth during certain points in the
video. (clearly the fps for SD is much higher)

The new results:
-----------------------------------------------------------------------------------------------

cfs-v6
700m kernel # cat sched_granularity_ns
0
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
8  0      0 894204    536 892388    0    0    45     0 4192 12237 57  7 35  0
0  0      0 893904    536 892708    0    0    88   139 4298 12511 55  7 29  9
4  0      0 893620    536 892964    0    0    85     0 4217 12189 55  5 39  0
0  0      0 890272    536 893220    0    0    85     0 4285 12366 55  7 38  0
4  0      0 881008    536 893348    0    0    43     0 4020 12610 59  6 35  0
5  0      0 882608    536 893848    0    0    43     0 3053 12045 81  6 13  0

top - 01:03:47 up 10 min,  7 users,  load average: 3.52, 2.81, 1.41
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
Cpu(s): 55.0%us,  6.3%sy,  0.0%ni, 37.3%id,  0.7%wa,  0.7%hi,  0.0%si,  0.0%st
Mem:   2057700k total,  1171508k used,   886192k free,      536k buffers
Swap:   987988k total,        0k used,   987988k free,   899704k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
20227 hechacke  20   0 51408  30m  18m S 22.9  1.5   1:44.30 gmplayer
20237 hechacke  20   0  128m  37m  18m S 14.0  1.9   0:28.88 mono
19931 root      20   0  271m  48m  15m S 11.0  2.4   0:52.76 Xorg
20214 hechacke  20   0  156m  51m  19m S 10.0  2.6   1:47.80 totem
20164 hechacke  20   0 63456 6332 4316 S  3.0  0.3   0:12.06 beryl

Observation:
Music plays perfectly.
Audio of video's play perfectly.
Processes start faster than sched_granularity_ns 2000000
Browsing the web faster than 2000000, but still not as fast as
mainline (better than cfs)
Already open applications are responsive.
Behavior of video:
video's both moving forward. totem is doing ~0.5fps.
mplayer is doing ~2 fps.
Visibly slower refreshing vs sched_granularity_ns 2000000

For some reason top doesn't seem reliable considering the system was
stressed at the time?
-
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/