Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote: > Have you tryied the 2 modes of the patch? Here's my stats for sched_yield_ctl = 2 loops fps 0 48 1 48 2 48 3 48 4 39 5 39 6 39 7 28 8 28 9 22 10 18 Once again it was very jerky come run-around-the-map time, though it improved over time. For me, still not as smooth as CFS was (especially the initial player movement, which was the worst by far of any test so far) I want to get some better numbers than plain fps though, the graph of the numbers is more staircase-like in this test but what it doesn't show is exactly what's going on. I can assure you the framerates may be similar but the gameplay isn't - and in this test 5fps difference is meaningless since it jumps around a lot (especially during the run-around) as you would expect with the different stuff needing to be rendered. -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Matthew Hawkins <[EMAIL PROTECTED]> wrote: > For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds > for initial load, same as CFS normally does for me. I think the 8 > second one was because I got in quick and the system was still running > some startup crap (so I blame disk i/o not the scheduler). I'll keep > an eye on it just in case, but hardly consider it a regression at this > stage. okay. If you suspect some regression then there are various ways to get less subjective metrics of delays. Firstly, you might want to look into desktop-action recorders to measure precise latencies of on-desktop sequences that are important to you. To get a 'cache cold' system you can do: echo 1 > /proc/sys/vm/drop_caches this zaps all the VM/vfs caches in the system, so you can do an arbitrary number of cache-cold and cache-hot measurements as well. Another source of information about desktop latencies is in the /proc//sched files if CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS is enabled. For example here's the delays of all my firefox threads: $ grep max /proc/`pidof firefox-bin`/task/*/sched | sort -t: -k 3 -n | tail -10 /proc/3016/task/3041/sched:se.exec_max : 15865 /proc/3016/task/3031/sched:se.exec_max : 31604 /proc/3016/task/3032/sched:se.exec_max : 46892 /proc/3016/task/3032/sched:se.wait_max : 511850 /proc/3016/task/3016/sched:se.exec_max : 1013570 /proc/3016/task/3016/sched:se.block_max :14870850 /proc/3016/task/3016/sched:se.wait_max :32558799 /proc/3016/task/3016/sched:se.sleep_max :87667199 /proc/3016/task/3032/sched:se.sleep_max : 430423009 /proc/3016/task/3031/sched:se.sleep_max : 1206545563 'sleep_max' values mean voluntary (interruptible) sleeps - those are usually harmless and dont cause human-visible latencies. The 'dangerous' ones are the block_max (maximum uninterruptible sleep - such as disk IO, lock contention or swap activities) and wait_max (maximum time a task got on the CPU) values. In the above list the largest wait_max was 32.5 msecs (all CFS units are in nanosecs), the largest block_max was 14.8 msecs - both are pretty OK. (you can clear the stats and start the measurement anew by echo-ing 0 to the /proc 'sched' files - without having to exit the app.) Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
> > this is what CFS does:
> >
> > static void yield_task_fair(struct rq *rq, struct task_struct *p)
> > {
> > struct cfs_rq *cfs_rq = task_cfs_rq(p);
> > u64 now = __rq_clock(rq);
> >
> > /*
> >* Dequeue and enqueue the task to update its
> >* position within the tree:
> >*/
> > dequeue_entity(cfs_rq, >se, 0, now);
> > enqueue_entity(cfs_rq, >se, 0, now);
> > }
> >
> > Ingo
>
> So the difference from mainline (2.6.22) is that now you removed
> requeue_task(), is that it?
No - I renamed requeue_task() to current->sched_class->yield_task(),
which does this for SCHED_OTHER:
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, >se, 0, now);
enqueue_entity(cfs_rq, >se, 0, now);
and this for RT tasks:
static void
yield_task_rt(struct rq *rq, struct task_struct *p)
{
requeue_task_rt(rq, p);
}
a dequeue+enqueue _is_ a requeue ...
Ingo
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Terça, 31 de Julho de 2007 16:57, Matthew Hawkins escreveu: > On 7/31/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote: > > CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as > > until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave > > like CFS then you are comparing apples to apples. > > Hi Miguel, > > I tested with sched_yield_ctl set to 1 > > 2.6.22.1-ck+sched_yield_hack > 0 51 > 1 51 > 2 51 > 3 46 > 4 38 > 5 38 > 6 38 > 7 30 > 8 27 > 9 22 > 10 20 > > After getting the numbers on all setups with the 10 loops still > running I went for a run around the map (I used the "aggressor" map, > if anyone cares). CFS was noticeably smoother (despite the small > framerate differences). ie CFS was bordering on barely playable, > whereas the above test it wasn't really playable (felt like playing on > a lagged server). Even plain -ck was better (going for a run, the FPS > jumped from ~2 to 15). I've noticed messing with sched_yield tends to > cause strange defects in the past... Have you tryied the 2 modes of the patch? -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > The only other thing of interest is that the -ck kernel had the WM > > menus appear in about 3 seconds rather than 5-8 under the other two. > > under what load is that - 10 loops? There's no disk or network IO going > on during a WM menu appearance, correct? Incorrect. This is before doing any tests whatsoever, just using the menu to get to the launcher for nexuiz. E-17 wants to load up pretty little icons next to every menu item, and "games" is fourth down the list of menus... the three above it contain practically everything else installed on the system (since it includes Applications). Thanks, debian menu! ;) So obviously on first load these things aren't cached yet (in E's own cache), so its madly searching the disk for pretty little icons. After caching, the games menu pops up in 2 seconds. For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds for initial load, same as CFS normally does for me. I think the 8 second one was because I got in quick and the system was still running some startup crap (so I blame disk i/o not the scheduler). I'll keep an eye on it just in case, but hardly consider it a regression at this stage. Thanks for the other experimentation hints, its always nice to have that little extra bit of documentation! -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Miguel Figueiredo <[EMAIL PROTECTED]> wrote: > CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until > 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS > then you are comparing apples to apples. Hi Miguel, I tested with sched_yield_ctl set to 1 2.6.22.1-ck+sched_yield_hack 0 51 1 51 2 51 3 46 4 38 5 38 6 38 7 30 8 27 9 22 10 20 After getting the numbers on all setups with the 10 loops still running I went for a run around the map (I used the "aggressor" map, if anyone cares). CFS was noticeably smoother (despite the small framerate differences). ie CFS was bordering on barely playable, whereas the above test it wasn't really playable (felt like playing on a lagged server). Even plain -ck was better (going for a run, the FPS jumped from ~2 to 15). I've noticed messing with sched_yield tends to cause strange defects in the past... -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Matthew Hawkins <[EMAIL PROTECTED]> wrote: > On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Kenneth Prugh <[EMAIL PROTECTED]> wrote: > > > CFS generally seemed a lot smoother as the load increased, while > > > SD broke down to a highly unstable fps count that fluctuated > > > massively around the third loop. Seems like I will stick to CFS > > > for gaming now. > > My experience was quite similar. I noticed after launching the second > loop that the FPS stuck down to 15 for about 20 seconds, then climbed > back up to 48. After that it went rapidly downhill. This is similar > to other benchmarks I've done of SD versus CFS in the past. At a > "normal" load they're fairly similar but SD breaks down under > pressure. ok, thanks for testing it! > The only other thing of interest is that the -ck kernel had the WM > menus appear in about 3 seconds rather than 5-8 under the other two. under what load is that - 10 loops? There's no disk or network IO going on during a WM menu appearance, correct? This could be a time-slicing difference perhaps - if you have CONFIG_HZ=100 could you change it to 1000 (or if you have it at 1000, could you change it to 100) - does it show any sensitivity to that? the other difference could be SCHED_FEAT_START_DEBIT, does that WM menu latency go down if you clear it from sched_features, i.e. to subtract 16 from sched_features: echo 15 > /proc/sys/kernel/sched_features to restore the default, do: echo 31 > /proc/sys/kernel/sched_features (if you have CONFIG_SCHED_DEBUG=y). You might also want to try changing /proc/sys/kernel/sched_granularity_ns. Boundary conditions: make sure that if you change the sched_granularity value you also set /proc/sys/kernel/sched_runtime_limit_ns to 2*sched_granularity and set /proc/sys/kernel/sched_wakeup_granularity_ns to sched_granularity/2. Other interesting bits to experiment with in sched_features would be SCHED_FEAT_FAIR_SLEEPERS (mask '1' in the bitmask) and SCHED_FEAT_SKIP_INITIAL (mask '32' in the bitmask). Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
> CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers)
> as until 2.6.22 and -ck. [...]
as i pointed it out to you it does, the function's name changed:
/*
* sched_yield() support is very simple - we dequeue and enqueue
*/
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
u64 now = __rq_clock(rq);
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, >se, 0, now);
enqueue_entity(cfs_rq, >se, 0, now);
}
plus others have tried the SD NOP-yield hack-patch and while it slightly
improved the SD numbers it did not change the "CFS is smoother"
experience.
Ingo
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Terça, 31 de Julho de 2007 14:16, Matthew Hawkins escreveu: > On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Kenneth Prugh <[EMAIL PROTECTED]> wrote: > > > CFS generally seemed a lot smoother as the load increased, while SD > > > broke down to a highly unstable fps count that fluctuated massively > > > around the third loop. Seems like I will stick to CFS for gaming now. > > My experience was quite similar. I noticed after launching the second > loop that the FPS stuck down to 15 for about 20 seconds, then climbed > back up to 48. After that it went rapidly downhill. This is similar > to other benchmarks I've done of SD versus CFS in the past. At a > "normal" load they're fairly similar but SD breaks down under > pressure. > The only other thing of interest is that the -ck kernel had the WM > menus appear in about 3 seconds rather than 5-8 under the other two. > > Game: Nexuiz 2.3 > OpenGL 2.0 shaders on > Vertex Buffer Objects on > Show FPS on > ultimate quality > 1024x768 > > 2.6.23-git > 0 48 > 1 48 > 2 48 > 3 48 > 4 40 > 5 38 > 6 33 > 7 28 > 8 22 > 9 22 > 10 18 > > 2.6.22.1-ck > 0 48 > 1 48 > 2 48 > 3 12 > 4 6 > 5 6 > 6 5 > 7 4 > 8 3 > 9 3 > 10 2 > > 2.6.22.1-cfs-v19.1+ckbits [*] > 0 48 > 1 48 > 2 48 > 3 46 > 4 45 > 5 43 > 6 36 > 7 32 > 8 25 > 9 24 > 10 24 > > [*] This kernel has the cfq-* and mm-* patches from -ck applied, and > the above-background-load function from pre-SD ck patchsets (or > 2.6.23-git) CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS then you are comparing apples to apples. Details on the SCHED_YIELD implementation on [2]. Please correct it if it's wrong. 1 - http://www.debianpt.org/~elmig/pool/kernel/20070731/sched_yield_hack.patch 2 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Kenneth Prugh <[EMAIL PROTECTED]> wrote: > > CFS generally seemed a lot smoother as the load increased, while SD > > broke down to a highly unstable fps count that fluctuated massively > > around the third loop. Seems like I will stick to CFS for gaming now. My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a "normal" load they're fairly similar but SD breaks down under pressure. The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. Game: Nexuiz 2.3 OpenGL 2.0 shaders on Vertex Buffer Objects on Show FPS on ultimate quality 1024x768 2.6.23-git 0 48 1 48 2 48 3 48 4 40 5 38 6 33 7 28 8 22 9 22 10 18 2.6.22.1-ck 0 48 1 48 2 48 3 12 4 6 5 6 6 5 7 4 8 3 9 3 10 2 2.6.22.1-cfs-v19.1+ckbits [*] 0 48 1 48 2 48 3 46 4 45 5 43 6 36 7 32 8 25 9 24 10 24 [*] This kernel has the cfq-* and mm-* patches from -ck applied, and the above-background-load function from pre-SD ck patchsets (or 2.6.23-git) -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kenneth Prugh <[EMAIL PROTECTED]> wrote: > Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 > CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a > map while not moving at all and always facing the same direction, > while slowing increasing the number of loops. > > CFS generally seemed a lot smoother as the load increased, while SD > broke down to a highly unstable fps count that fluctuated massively > around the third loop. Seems like I will stick to CFS for gaming now. > > Below you will find the results of my test with the average number of > FPS. Thanks Kenneth for the testing! I've created a graph out of your numbers: http://people.redhat.com/mingo/misc/cfs-sd-ut2004-perf.jpg (it also includes the SD numbers you got with the turn-yield-into-NOP hack applied.) Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* kriko <[EMAIL PROTECTED]> wrote: > I'm trying to get kernel 2.6.22-ck and 2.6.23-rc1 work to test the new > cfs scheduler, but I get broken system. Networking is totally broken > (cannot find module for my marvell yukon gigabit ethernet in kconfig), > firewall / routing doesn't work (a bunch of error messages when > firewall script starts). Were there drastic changes in networking > support? Currently I'm running 2.6.21-ck1 on opensuse 10.2 and it > works fine. pick up 2.6.22-cfsv19 from: http://people.redhat.com/mingo/cfs-scheduler/ 2.6.23-rc1 is indeed a bit experimental. Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* kriko [EMAIL PROTECTED] wrote: I'm trying to get kernel 2.6.22-ck and 2.6.23-rc1 work to test the new cfs scheduler, but I get broken system. Networking is totally broken (cannot find module for my marvell yukon gigabit ethernet in kconfig), firewall / routing doesn't work (a bunch of error messages when firewall script starts). Were there drastic changes in networking support? Currently I'm running 2.6.21-ck1 on opensuse 10.2 and it works fine. pick up 2.6.22-cfsv19 from: http://people.redhat.com/mingo/cfs-scheduler/ 2.6.23-rc1 is indeed a bit experimental. Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kenneth Prugh [EMAIL PROTECTED] wrote: Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map while not moving at all and always facing the same direction, while slowing increasing the number of loops. CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. Below you will find the results of my test with the average number of FPS. Thanks Kenneth for the testing! I've created a graph out of your numbers: http://people.redhat.com/mingo/misc/cfs-sd-ut2004-perf.jpg (it also includes the SD numbers you got with the turn-yield-into-NOP hack applied.) Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a normal load they're fairly similar but SD breaks down under pressure. The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. Game: Nexuiz 2.3 OpenGL 2.0 shaders on Vertex Buffer Objects on Show FPS on ultimate quality 1024x768 2.6.23-git 0 48 1 48 2 48 3 48 4 40 5 38 6 33 7 28 8 22 9 22 10 18 2.6.22.1-ck 0 48 1 48 2 48 3 12 4 6 5 6 6 5 7 4 8 3 9 3 10 2 2.6.22.1-cfs-v19.1+ckbits [*] 0 48 1 48 2 48 3 46 4 45 5 43 6 36 7 32 8 25 9 24 10 24 [*] This kernel has the cfq-* and mm-* patches from -ck applied, and the above-background-load function from pre-SD ck patchsets (or 2.6.23-git) -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Terça, 31 de Julho de 2007 14:16, Matthew Hawkins escreveu: On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a normal load they're fairly similar but SD breaks down under pressure. The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. Game: Nexuiz 2.3 OpenGL 2.0 shaders on Vertex Buffer Objects on Show FPS on ultimate quality 1024x768 2.6.23-git 0 48 1 48 2 48 3 48 4 40 5 38 6 33 7 28 8 22 9 22 10 18 2.6.22.1-ck 0 48 1 48 2 48 3 12 4 6 5 6 6 5 7 4 8 3 9 3 10 2 2.6.22.1-cfs-v19.1+ckbits [*] 0 48 1 48 2 48 3 46 4 45 5 43 6 36 7 32 8 25 9 24 10 24 [*] This kernel has the cfq-* and mm-* patches from -ck applied, and the above-background-load function from pre-SD ck patchsets (or 2.6.23-git) CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS then you are comparing apples to apples. Details on the SCHED_YIELD implementation on [2]. Please correct it if it's wrong. 1 - http://www.debianpt.org/~elmig/pool/kernel/20070731/sched_yield_hack.patch 2 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Miguel Figueiredo [EMAIL PROTECTED] wrote:
CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers)
as until 2.6.22 and -ck. [...]
as i pointed it out to you it does, the function's name changed:
/*
* sched_yield() support is very simple - we dequeue and enqueue
*/
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
u64 now = __rq_clock(rq);
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, p-se, 0, now);
enqueue_entity(cfs_rq, p-se, 0, now);
}
plus others have tried the SD NOP-yield hack-patch and while it slightly
improved the SD numbers it did not change the CFS is smoother
experience.
Ingo
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Matthew Hawkins [EMAIL PROTECTED] wrote: On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. My experience was quite similar. I noticed after launching the second loop that the FPS stuck down to 15 for about 20 seconds, then climbed back up to 48. After that it went rapidly downhill. This is similar to other benchmarks I've done of SD versus CFS in the past. At a normal load they're fairly similar but SD breaks down under pressure. ok, thanks for testing it! The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. under what load is that - 10 loops? There's no disk or network IO going on during a WM menu appearance, correct? This could be a time-slicing difference perhaps - if you have CONFIG_HZ=100 could you change it to 1000 (or if you have it at 1000, could you change it to 100) - does it show any sensitivity to that? the other difference could be SCHED_FEAT_START_DEBIT, does that WM menu latency go down if you clear it from sched_features, i.e. to subtract 16 from sched_features: echo 15 /proc/sys/kernel/sched_features to restore the default, do: echo 31 /proc/sys/kernel/sched_features (if you have CONFIG_SCHED_DEBUG=y). You might also want to try changing /proc/sys/kernel/sched_granularity_ns. Boundary conditions: make sure that if you change the sched_granularity value you also set /proc/sys/kernel/sched_runtime_limit_ns to 2*sched_granularity and set /proc/sys/kernel/sched_wakeup_granularity_ns to sched_granularity/2. Other interesting bits to experiment with in sched_features would be SCHED_FEAT_FAIR_SLEEPERS (mask '1' in the bitmask) and SCHED_FEAT_SKIP_INITIAL (mask '32' in the bitmask). Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Miguel Figueiredo [EMAIL PROTECTED] wrote: CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS then you are comparing apples to apples. Hi Miguel, I tested with sched_yield_ctl set to 1 2.6.22.1-ck+sched_yield_hack 0 51 1 51 2 51 3 46 4 38 5 38 6 38 7 30 8 27 9 22 10 20 After getting the numbers on all setups with the 10 loops still running I went for a run around the map (I used the aggressor map, if anyone cares). CFS was noticeably smoother (despite the small framerate differences). ie CFS was bordering on barely playable, whereas the above test it wasn't really playable (felt like playing on a lagged server). Even plain -ck was better (going for a run, the FPS jumped from ~2 to 15). I've noticed messing with sched_yield tends to cause strange defects in the past... -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Ingo Molnar [EMAIL PROTECTED] wrote: The only other thing of interest is that the -ck kernel had the WM menus appear in about 3 seconds rather than 5-8 under the other two. under what load is that - 10 loops? There's no disk or network IO going on during a WM menu appearance, correct? Incorrect. This is before doing any tests whatsoever, just using the menu to get to the launcher for nexuiz. E-17 wants to load up pretty little icons next to every menu item, and games is fourth down the list of menus... the three above it contain practically everything else installed on the system (since it includes Applications). Thanks, debian menu! ;) So obviously on first load these things aren't cached yet (in E's own cache), so its madly searching the disk for pretty little icons. After caching, the games menu pops up in 2 seconds. For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds for initial load, same as CFS normally does for me. I think the 8 second one was because I got in quick and the system was still running some startup crap (so I blame disk i/o not the scheduler). I'll keep an eye on it just in case, but hardly consider it a regression at this stage. Thanks for the other experimentation hints, its always nice to have that little extra bit of documentation! -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Terça, 31 de Julho de 2007 16:57, Matthew Hawkins escreveu: On 7/31/07, Miguel Figueiredo [EMAIL PROTECTED] wrote: CFS does not requeue_task() on SCHED_YIELD (used by graphic drivers) as until 2.6.22 and -ck. Please try this hack [1] that makes -ck to behave like CFS then you are comparing apples to apples. Hi Miguel, I tested with sched_yield_ctl set to 1 2.6.22.1-ck+sched_yield_hack 0 51 1 51 2 51 3 46 4 38 5 38 6 38 7 30 8 27 9 22 10 20 After getting the numbers on all setups with the 10 loops still running I went for a run around the map (I used the aggressor map, if anyone cares). CFS was noticeably smoother (despite the small framerate differences). ie CFS was bordering on barely playable, whereas the above test it wasn't really playable (felt like playing on a lagged server). Even plain -ck was better (going for a run, the FPS jumped from ~2 to 15). I've noticed messing with sched_yield tends to cause strange defects in the past... Have you tryied the 2 modes of the patch? -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Miguel Figueiredo [EMAIL PROTECTED] wrote:
this is what CFS does:
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
u64 now = __rq_clock(rq);
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, p-se, 0, now);
enqueue_entity(cfs_rq, p-se, 0, now);
}
Ingo
So the difference from mainline (2.6.22) is that now you removed
requeue_task(), is that it?
No - I renamed requeue_task() to current-sched_class-yield_task(),
which does this for SCHED_OTHER:
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, p-se, 0, now);
enqueue_entity(cfs_rq, p-se, 0, now);
and this for RT tasks:
static void
yield_task_rt(struct rq *rq, struct task_struct *p)
{
requeue_task_rt(rq, p);
}
a dequeue+enqueue _is_ a requeue ...
Ingo
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Matthew Hawkins [EMAIL PROTECTED] wrote: For the newly-tested kernel (-ck+sched_yield_hack) it was 4-5 seconds for initial load, same as CFS normally does for me. I think the 8 second one was because I got in quick and the system was still running some startup crap (so I blame disk i/o not the scheduler). I'll keep an eye on it just in case, but hardly consider it a regression at this stage. okay. If you suspect some regression then there are various ways to get less subjective metrics of delays. Firstly, you might want to look into desktop-action recorders to measure precise latencies of on-desktop sequences that are important to you. To get a 'cache cold' system you can do: echo 1 /proc/sys/vm/drop_caches this zaps all the VM/vfs caches in the system, so you can do an arbitrary number of cache-cold and cache-hot measurements as well. Another source of information about desktop latencies is in the /proc/PID/sched files if CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS is enabled. For example here's the delays of all my firefox threads: $ grep max /proc/`pidof firefox-bin`/task/*/sched | sort -t: -k 3 -n | tail -10 /proc/3016/task/3041/sched:se.exec_max : 15865 /proc/3016/task/3031/sched:se.exec_max : 31604 /proc/3016/task/3032/sched:se.exec_max : 46892 /proc/3016/task/3032/sched:se.wait_max : 511850 /proc/3016/task/3016/sched:se.exec_max : 1013570 /proc/3016/task/3016/sched:se.block_max :14870850 /proc/3016/task/3016/sched:se.wait_max :32558799 /proc/3016/task/3016/sched:se.sleep_max :87667199 /proc/3016/task/3032/sched:se.sleep_max : 430423009 /proc/3016/task/3031/sched:se.sleep_max : 1206545563 'sleep_max' values mean voluntary (interruptible) sleeps - those are usually harmless and dont cause human-visible latencies. The 'dangerous' ones are the block_max (maximum uninterruptible sleep - such as disk IO, lock contention or swap activities) and wait_max (maximum time a task got on the CPU) values. In the above list the largest wait_max was 32.5 msecs (all CFS units are in nanosecs), the largest block_max was 14.8 msecs - both are pretty OK. (you can clear the stats and start the measurement anew by echo-ing 0 to the /proc 'sched' files - without having to exit the app.) Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 8/1/07, Miguel Figueiredo [EMAIL PROTECTED] wrote: Have you tryied the 2 modes of the patch? Here's my stats for sched_yield_ctl = 2 loops fps 0 48 1 48 2 48 3 48 4 39 5 39 6 39 7 28 8 28 9 22 10 18 Once again it was very jerky come run-around-the-map time, though it improved over time. For me, still not as smooth as CFS was (especially the initial player movement, which was the worst by far of any test so far) I want to get some better numbers than plain fps though, the graph of the numbers is more staircase-like in this test but what it doesn't show is exactly what's going on. I can assure you the framerates may be similar but the gameplay isn't - and in this test 5fps difference is meaningless since it jumps around a lot (especially during the run-around) as you would expect with the different stuff needing to be rendered. -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Miguel Figueiredo wrote: > Em Segunda, 30 de Julho de 2007 22:24, Kenneth Prugh escreveu: >> Ingo Molnar wrote: >>> * Kenneth Prugh <[EMAIL PROTECTED]> wrote: Ingo Molnar wrote: > Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? >>> .22-ck1 includes it, so that should be fine: >>> >>> http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html >>> >>> Ingo >> Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 >> CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map >> while not moving at all and always facing the same direction, while >> slowing increasing the number of loops. >> >> CFS generally seemed a lot smoother as the load increased, while SD >> broke down to a highly unstable fps count that fluctuated massively >> around the third loop. Seems like I will stick to CFS for gaming now. >> >> Below you will find the results of my test with the average number of FPS. >> >> CFS | SD >> UT2004 + 0 loops | 200 FPS UT2004 + 0 loops | 190 FPS >> UT2004 + 1 loops | 195 FPS UT2004 + 1 loops | 190 FPS >> UT2004 + 2 loops | 190 FPS UT2004 + 2 loops | 190 FPS >> UT2004 + 3 loops | 189 FPS UT2004 + 3 loops | 136 FPS >> UT2004 + 4 loops | 150 FPS UT2004 + 4 loops | 137 FPS >> UT2004 + 5 loops | 145 FPS UT2004 + 5 loops | 136 FPS >> UT2004 + 6 loops | 145 FPS UT2004 + 6 loops | 105 FPS >> UT2004 + 7 loops | 118 FPS UT2004 + 7 loops | 104 FPS >> UT2004 + 8 loops | 97 FPSUT2004 + 8 loops | 104 FPS >> UT2004 + 9 loops | 94 FPSUT2004 + 9 loops | 89 FPS >> UT2004 + 10 loops | 92 FPS UT2004 + 10 loops | 91 FPS > > can you apply the patch [1] that changes the behaviour of sched_yield on SD > and report the results? > > SD should scale a lot better after the patch. > > 1 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html > I Applied the patch. SD Seemed a bit smoother over the loads, although that could be a placebo effect. It wasn't until the 8 or 9th loop running that I could really notice that the fps were fluctuating in the map without looking at the fps counter. SD-Patched UT2004 + 0 loops | 202 FPS UT2004 + 1 loops | 201 FPS UT2004 + 2 loops | 199 FPS UT2004 + 3 loops | 143 FPS UT2004 + 4 loops | 145 FPS UT2004 + 5 loops | 145 FPS UT2004 + 6 loops | 112 FPS UT2004 + 7 loops | 110 FPS UT2004 + 8 loops | 108 FPS UT2004 + 9 loops | 90 FPS UT2004 + 10 loops | 89 FPS -- Kenneth Prugh - Ken69267 Gentoo AMD64 Arch Tester signature.asc Description: OpenPGP digital signature
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Segunda, 30 de Julho de 2007 22:24, Kenneth Prugh escreveu: > Ingo Molnar wrote: > > * Kenneth Prugh <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: > >>> > >> > >> Hello, I have a gaming rig and would love to help benchmark with my > >> copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have > >> anything else that would better serve as a benchmark I could grab it > >> and try. > >> > >> The only problem is I don't know what 2 kernels I should be using to > >> test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? > > > > .22-ck1 includes it, so that should be fine: > > > > http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html > > > > Ingo > > Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 > CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map > while not moving at all and always facing the same direction, while > slowing increasing the number of loops. > > CFS generally seemed a lot smoother as the load increased, while SD > broke down to a highly unstable fps count that fluctuated massively > around the third loop. Seems like I will stick to CFS for gaming now. > > Below you will find the results of my test with the average number of FPS. > > CFS | SD > UT2004 + 0 loops | 200 FPSUT2004 + 0 loops | 190 FPS > UT2004 + 1 loops | 195 FPSUT2004 + 1 loops | 190 FPS > UT2004 + 2 loops | 190 FPSUT2004 + 2 loops | 190 FPS > UT2004 + 3 loops | 189 FPSUT2004 + 3 loops | 136 FPS > UT2004 + 4 loops | 150 FPSUT2004 + 4 loops | 137 FPS > UT2004 + 5 loops | 145 FPSUT2004 + 5 loops | 136 FPS > UT2004 + 6 loops | 145 FPSUT2004 + 6 loops | 105 FPS > UT2004 + 7 loops | 118 FPSUT2004 + 7 loops | 104 FPS > UT2004 + 8 loops | 97 FPS UT2004 + 8 loops | 104 FPS > UT2004 + 9 loops | 94 FPS UT2004 + 9 loops | 89 FPS > UT2004 + 10 loops | 92 FPSUT2004 + 10 loops | 91 FPS can you apply the patch [1] that changes the behaviour of sched_yield on SD and report the results? SD should scale a lot better after the patch. 1 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Ingo Molnar wrote: > * Kenneth Prugh <[EMAIL PROTECTED]> wrote: > >> Ingo Molnar wrote: >>> >> Hello, I have a gaming rig and would love to help benchmark with my >> copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have >> anything else that would better serve as a benchmark I could grab it >> and try. >> >> The only problem is I don't know what 2 kernels I should be using to >> test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? > > .22-ck1 includes it, so that should be fine: > > http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html > > Ingo > Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map while not moving at all and always facing the same direction, while slowing increasing the number of loops. CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. Below you will find the results of my test with the average number of FPS. CFS | SD UT2004 + 0 loops | 200 FPS UT2004 + 0 loops | 190 FPS UT2004 + 1 loops | 195 FPS UT2004 + 1 loops | 190 FPS UT2004 + 2 loops | 190 FPS UT2004 + 2 loops | 190 FPS UT2004 + 3 loops | 189 FPS UT2004 + 3 loops | 136 FPS UT2004 + 4 loops | 150 FPS UT2004 + 4 loops | 137 FPS UT2004 + 5 loops | 145 FPS UT2004 + 5 loops | 136 FPS UT2004 + 6 loops | 145 FPS UT2004 + 6 loops | 105 FPS UT2004 + 7 loops | 118 FPS UT2004 + 7 loops | 104 FPS UT2004 + 8 loops | 97 FPS UT2004 + 8 loops | 104 FPS UT2004 + 9 loops | 94 FPS UT2004 + 9 loops | 89 FPS UT2004 + 10 loops | 92 FPS UT2004 + 10 loops | 91 FPS -- Kenneth Prugh signature.asc Description: OpenPGP digital signature
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Segunda, 30 de Julho de 2007 19:38, Ingo Molnar escreveu:
> * Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
> > in mainline (2.6.22):
> > /**
> > * sys_sched_yield - yield the current processor to other threads.
> > *
> > * This function yields the current CPU by moving the calling thread
> > * to the expired array. If there are no other threads running on this
> > * CPU then this function will return.
> > */
> >
[...]
> this is what CFS does:
>
> static void yield_task_fair(struct rq *rq, struct task_struct *p)
> {
> struct cfs_rq *cfs_rq = task_cfs_rq(p);
> u64 now = __rq_clock(rq);
>
> /*
>* Dequeue and enqueue the task to update its
>* position within the tree:
>*/
> dequeue_entity(cfs_rq, >se, 0, now);
> enqueue_entity(cfs_rq, >se, 0, now);
> }
>
> Ingo
So the difference from mainline (2.6.22) is that now you removed
requeue_task(), is that it?
--
Com os melhores cumprimentos/Best regards,
Miguel Figueiredo
http://www.DebianPT.org
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kenneth Prugh <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > > > Hello, I have a gaming rig and would love to help benchmark with my > copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have > anything else that would better serve as a benchmark I could grab it > and try. > > The only problem is I don't know what 2 kernels I should be using to > test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? .22-ck1 includes it, so that should be fine: http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > ah, you mean Kasper Sandberg's report? That turned out to be based > > on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his > > tests, and if there's still any regression left we'll fix it. > > probably. I delete lkml messages pretty agressivly so I don't have > them around to refer to. lkml.org is your friend: http://lkml.org/lkml/2007/7/27/423 http://lkml.org/lkml/2007/7/28/50 http://lkml.org/lkml/2007/7/30/195 :-) Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Mon, 30 Jul 2007, Ingo Molnar wrote: * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. the one report that I saw said that the FPS numbers were overall the same, but what the reporter was seeing was that CFS was doing it in bursts of activity while SD was smoother. [...] which report is that, precisely? I'm not aware of any such report past CFS v14 or so. IIRC Linus responded with thoughts on granularity and the fact that changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 10x (which could be enough to trigger this sort of issue) ah, you mean Kasper Sandberg's report? That turned out to be based on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests, and if there's still any regression left we'll fix it. probably. I delete lkml messages pretty agressivly so I don't have them around to refer to. David Lang - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Would you be interested in trying CFS and doing some numers perhaps? > > It requires some work: you have to start up your favorite game in a > > way that gives a reliable framerate number. (many games allow the > > display of FPS in-game) In Quake3 i simply started the game and did > > not move the player - that is something easy to reproduce. > > the one report that I saw said that the FPS numbers were overall the > same, but what the reporter was seeing was that CFS was doing it in > bursts of activity while SD was smoother. [...] which report is that, precisely? I'm not aware of any such report past CFS v14 or so. > IIRC Linus responded with thoughts on granularity and the fact that > changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by > 10x (which could be enough to trigger this sort of issue) ah, you mean Kasper Sandberg's report? That turned out to be based on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests, and if there's still any regression left we'll fix it. Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Miguel Figueiredo <[EMAIL PROTECTED]> wrote:
> in mainline (2.6.22):
> /**
> * sys_sched_yield - yield the current processor to other threads.
> *
> * This function yields the current CPU by moving the calling thread
> * to the expired array. If there are no other threads running on this
> * CPU then this function will return.
> */
>
> you changed it to something like:
>
> if (unlikely(rq->nr_running == 1))
> schedstat_inc(rq, yld_act_empty);
> else
> current->sched_class->yield_task(rq, current);
>
> wile mainline (2.6.22) and SD use:
>
> dequeue_task(current, array);
> enqueue_task(current, target);
this is what CFS does:
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
u64 now = __rq_clock(rq);
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, >se, 0, now);
enqueue_entity(cfs_rq, >se, 0, now);
}
Ingo
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, Jul 31, 2007 at 02:25:47AM +1000, Matthew Hawkins wrote: > > The ATI drivers (current 8.39.4) were broken by > commit e21ea246bce5bb93dd822de420172ec280aed492 > Author: Martin Schwidefsky <[EMAIL PROTECTED]> > > Bad call on the "nobody was using these", Martin :( Sorry to use foul language once again after a while, but: Fuck you Martin! not only is complaining about illegal binary crap totally offtopic on this list, and making youself a fool for using that piece of shit is annoying enough, but don't even try to badmouth Martin for doing important and needed cleanups. And now get out of here! - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Ingo Molnar wrote: > Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? -- Kenneth Prugh signature.asc Description: OpenPGP digital signature
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote: > On 7/31/07, Jacob Braun <[EMAIL PROTECTED]> wrote: > > On 7/30/07, kriko <[EMAIL PROTECTED]> wrote: > > > I would try the new cfs how it performs, but it seems that nvidia drivers > > > doesn't compile successfully under 2.6.23-rc1. > > > http://files.myopera.com/kriko/files/nvidia-installer.log > > > > > > If someone has the solution, please share. > > > > There is a patch for the nvidia drivers here: > > http://bugs.gentoo.org/attachment.cgi?id=125959 > > The ATI drivers (current 8.39.4) were broken by > commit e21ea246bce5bb93dd822de420172ec280aed492 > Author: Martin Schwidefsky <[EMAIL PROTECTED]> some fo these binary drivers do really really bad stuff (esp the AMD ones are infamous for that) and it's no surprise they might throw of a new scheduler. In fact, that's a bonus, some of those hacks are workarounds for older (often 2.4) scheduler corner cases and should just be removed from the driver to get better performance. Holding back linux for such hacky junk in binary drivers would be the absolute worst thing to do; even for people who insist on using these drivers over the open source ones, since the next rev of these drivers can now use the new scheduler and actually be faster with all the workarounds removed. Very likely the best thing to do is to contact the supplier of the driver (AMD or Nvidia) and ask them to fix it. - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
> As for breaking binary crap, thats a bonus. Break them hard, break them > often. > I think there's a big difference in philosophy between "break binary drivers if you want to make a legitimate change for whatever reason" and "break binary drivers just to be a pain in the ass to the developers and users of said drivers." I think most people here agree with the first. It's unclear to me how many here agree with the second, but I know it's at least one. ;-) Kyle - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Martin Schwidefsky wrote: Do we care ? The code should be replaced with ptep_get_and_clear + pte_modify anyway.. Since the general direction of this thread was for people to test 3D game performance with the shiny new CFS cpu scheduler, I would say yes, we do care if people with the only 2 types of gaming caliber Video cards can get said video cards working, right now, with said shiny new kernel. Yes yes, I know, kernel devs don't care if they break binary drivers... and in principle, I agree with that philosophy.. but it's still damn inconvenient at times :) - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote: > On 7/31/07, Jacob Braun <[EMAIL PROTECTED]> wrote: > > On 7/30/07, kriko <[EMAIL PROTECTED]> wrote: > > > I would try the new cfs how it performs, but it seems that nvidia drivers > > > doesn't compile successfully under 2.6.23-rc1. > > > http://files.myopera.com/kriko/files/nvidia-installer.log > > > > > > If someone has the solution, please share. > > > > There is a patch for the nvidia drivers here: > > http://bugs.gentoo.org/attachment.cgi?id=125959 > > The ATI drivers (current 8.39.4) were broken by > commit e21ea246bce5bb93dd822de420172ec280aed492 > Author: Martin Schwidefsky <[EMAIL PROTECTED]> > > Bad call on the "nobody was using these", Martin :( Nobody in the upstream kernel did, and that is what matters. If you care about your kernel code get it upstream. As for breaking binary crap, thats a bonus. Break them hard, break them often. Kudos to Martin. - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote: > On 7/31/07, Jacob Braun <[EMAIL PROTECTED]> wrote: > > On 7/30/07, kriko <[EMAIL PROTECTED]> wrote: > > > I would try the new cfs how it performs, but it seems that nvidia drivers > > > doesn't compile successfully under 2.6.23-rc1. > > > http://files.myopera.com/kriko/files/nvidia-installer.log > > > > > > If someone has the solution, please share. > > > > There is a patch for the nvidia drivers here: > > http://bugs.gentoo.org/attachment.cgi?id=125959 > > The ATI drivers (current 8.39.4) were broken by > commit e21ea246bce5bb93dd822de420172ec280aed492 > Author: Martin Schwidefsky <[EMAIL PROTECTED]> > > Bad call on the "nobody was using these", Martin :( Do we care ? The code should be replaced with ptep_get_and_clear + pte_modify anyway.. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Segunda, 30 de Julho de 2007 12:46, Ingo Molnar escreveu: > * John <[EMAIL PROTECTED]> wrote: > > On 7/29/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > * John <[EMAIL PROTECTED]> wrote: > > > > Ingo- > > > > > > > > Why not perform the same test using the native linux Q3 client to > > > > compare numbers to wine? [...] [...] > and that matches my experience as well (as limited as it may be). In > general my impression is that CFS and SD are roughly on par when it > comes to 3D smoothness. > > The Wine+Quake3 numbers i posted yesterday are so bad under SD that they > must be some artifact in SD (possibly related to yield - i've strace-ed > the tasks under SD today and they are blocking in yield), so they are > not really representative of the general quality of SD (unless you are > being hit by that particular regression). Still it is kind of ironic > that when i tried to find a 3D regression in CFS i found a 3D regression > in SD. I also tryied Q3A demo and i got similar values to yours: CFS 90 2.6.22 90 SD 90 while running that endless loop, on 2.6.22 and SD it drops instantly to 4 fps. While CFS runs ~70 with 1.9 load. I was able to play the game without noticing much degradation. I written these values while playing under CFS: load fps 1.6681 1.7375 1.9770s With this patch [1] someone sent me over IRC i get similar values to CFS, maybe a few fps more, but thats insignificant and not very accurate to measure. Anyway with this patch i am playing with a load of 2.2 at ~75 fps, 1024x768 windowed. It's enjoyable to frag the dumb 'Major' as under CFS. I think the main difference in performance of CFS and SD it's the implementation of sched_yield (which is used by graphic drivers) and CFS has changed the implementation of sched_yield. You use: in mainline (2.6.22): /** * sys_sched_yield - yield the current processor to other threads. * * This function yields the current CPU by moving the calling thread * to the expired array. If there are no other threads running on this * CPU then this function will return. */ you changed it to something like: if (unlikely(rq->nr_running == 1)) schedstat_inc(rq, yld_act_empty); else current->sched_class->yield_task(rq, current); wile mainline (2.6.22) and SD use: dequeue_task(current, array); enqueue_task(current, target); and requeue_task() Anyway i am going to continue to frag a bit more :) [1] - http://rafb.net/p/Rbpqaz26.html There are 2 modes for this hack: sysctl kernel.sched_yield = 1 or 2, see patch. [...] > > Ingo > ___ > http://ck.kolivas.org/faqs/replying-to-mailing-list.txt > ck mailing list - mailto: [EMAIL PROTECTED] > http://vds.kolivas.org/mailman/listinfo/ck -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Jacob Braun <[EMAIL PROTECTED]> wrote: > On 7/30/07, kriko <[EMAIL PROTECTED]> wrote: > > I would try the new cfs how it performs, but it seems that nvidia drivers > > doesn't compile successfully under 2.6.23-rc1. > > http://files.myopera.com/kriko/files/nvidia-installer.log > > > > If someone has the solution, please share. > > There is a patch for the nvidia drivers here: > http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky <[EMAIL PROTECTED]> Bad call on the "nobody was using these", Martin :( -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Mon, 30 Jul 2007, Ingo Molnar wrote: * John <[EMAIL PROTECTED]> wrote: On 7/29/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: * John <[EMAIL PROTECTED]> wrote: Ingo- Why not perform the same test using the native linux Q3 client to compare numbers to wine? [...] I regularly test native Linux games on CFS, and they all behave well. While waiting for more detailed data from Kasper i was looking for atypical stuff in Kasper's description about what his workload involves, and what looked a bit atypical was that Kasper's workload also involved gaming under Wine: I understand that, I was just wondering if the FPS scales the same natively vs. Wine as I typically only run native games. [...] people are regularly testing 3D smoothness, and they find CFS good enough: http://bhhdoa.org.au/pipermail/ck/2007-June/007816.html and that matches my experience as well (as limited as it may be). In general my impression is that CFS and SD are roughly on par when it comes to 3D smoothness. i have no numbers now, other than the trivial native 'ppracer' game where SD and CFS have roughly the same framerate under load: SD CFS which i'd have expected, ppracer is quite CPU-intense on my test-system, and the fairness model of SD and CFS is similar for CPU-bound tasks. But ... numbers from _me_ are suspect by definition, i wrote a good chunk of the CFS code :-) So it would be much more interesting if others provided more numbers. Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. the one report that I saw said that the FPS numbers were overall the same, but what the reporter was seeing was that CFS was doing it in bursts of activity while SD was smoother. this wasn't enough to show up in the fps numbers being reported, but was enough to be unreasonable for gameing. IIRC Linus responded with thoughts on granularity and the fact that changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 10x (which could be enough to trigger this sort of issue) David Lang - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* John <[EMAIL PROTECTED]> wrote: > On 7/29/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > > * John <[EMAIL PROTECTED]> wrote: > > > > > Ingo- > > > > > > Why not perform the same test using the native linux Q3 client to > > > compare numbers to wine? [...] > > > > I regularly test native Linux games on CFS, and they all behave well. > > While waiting for more detailed data from Kasper i was looking for > > atypical stuff in Kasper's description about what his workload involves, > > and what looked a bit atypical was that Kasper's workload also involved > > gaming under Wine: > > I understand that, I was just wondering if the FPS scales the same > natively vs. Wine as I typically only run native games. [...] people are regularly testing 3D smoothness, and they find CFS good enough: http://bhhdoa.org.au/pipermail/ck/2007-June/007816.html and that matches my experience as well (as limited as it may be). In general my impression is that CFS and SD are roughly on par when it comes to 3D smoothness. The Wine+Quake3 numbers i posted yesterday are so bad under SD that they must be some artifact in SD (possibly related to yield - i've strace-ed the tasks under SD today and they are blocking in yield), so they are not really representative of the general quality of SD (unless you are being hit by that particular regression). Still it is kind of ironic that when i tried to find a 3D regression in CFS i found a 3D regression in SD. What is more interesting (to me) is not the positive CFS feedback but negative CFS feedback (although positive feedback certain _feels_ good so dont hold it back intentionally ;-), and i cannot possibly give you any definitive answer: at this point CFS could still have artifacts and bugs, so "check and see yourself" is the best answer. All i can tell you is that there are no open 3D related regressions for CFS at the moment. > [...] I have been hesitant to move over to CFS due to reports of 3D > issues and wanted to see if you had numbers in regards to CFS vs. SD. i have no numbers now, other than the trivial native 'ppracer' game where SD and CFS have roughly the same framerate under load: SD CFS 0: 38.1 0: 38.1 1: 24.0 1: 24.2 2: 16.6 2: 16.1 3: 11.9 3: 12.3 4: 9.9 4: 9.7 5: 8.2 5: 8.1 which i'd have expected, ppracer is quite CPU-intense on my test-system, and the fairness model of SD and CFS is similar for CPU-bound tasks. But ... numbers from _me_ are suspect by definition, i wrote a good chunk of the CFS code :-) So it would be much more interesting if others provided more numbers. Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. then create load the following way, by entering this into a shell: while :; do :; done & that will cause a shell to just loop infinitely, hogging the CPU. This is the "1 loop" case in the numbers i posted. Start several of them to get more. (Type 'killall bash' in the same terminal to get rid of them.) Monitor how the FPS of your game changes when you start more and more CPU hogs, and note the numbers. Repeat it under SD and CFS as well, and please post the results into this thread. and note that CPU hogs are just one type of 'load' that a system can experience - IO load or networking load could impact your in-game experience just as much. If you see any artifact or FPS reduction under CFS i'll give you further info about how to debug it (were you interested in debugging it). Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* John [EMAIL PROTECTED] wrote: On 7/29/07, Ingo Molnar [EMAIL PROTECTED] wrote: * John [EMAIL PROTECTED] wrote: Ingo- Why not perform the same test using the native linux Q3 client to compare numbers to wine? [...] I regularly test native Linux games on CFS, and they all behave well. While waiting for more detailed data from Kasper i was looking for atypical stuff in Kasper's description about what his workload involves, and what looked a bit atypical was that Kasper's workload also involved gaming under Wine: I understand that, I was just wondering if the FPS scales the same natively vs. Wine as I typically only run native games. [...] people are regularly testing 3D smoothness, and they find CFS good enough: http://bhhdoa.org.au/pipermail/ck/2007-June/007816.html and that matches my experience as well (as limited as it may be). In general my impression is that CFS and SD are roughly on par when it comes to 3D smoothness. The Wine+Quake3 numbers i posted yesterday are so bad under SD that they must be some artifact in SD (possibly related to yield - i've strace-ed the tasks under SD today and they are blocking in yield), so they are not really representative of the general quality of SD (unless you are being hit by that particular regression). Still it is kind of ironic that when i tried to find a 3D regression in CFS i found a 3D regression in SD. What is more interesting (to me) is not the positive CFS feedback but negative CFS feedback (although positive feedback certain _feels_ good so dont hold it back intentionally ;-), and i cannot possibly give you any definitive answer: at this point CFS could still have artifacts and bugs, so check and see yourself is the best answer. All i can tell you is that there are no open 3D related regressions for CFS at the moment. [...] I have been hesitant to move over to CFS due to reports of 3D issues and wanted to see if you had numbers in regards to CFS vs. SD. i have no numbers now, other than the trivial native 'ppracer' game where SD and CFS have roughly the same framerate under load: SD CFS 0: 38.1 0: 38.1 1: 24.0 1: 24.2 2: 16.6 2: 16.1 3: 11.9 3: 12.3 4: 9.9 4: 9.7 5: 8.2 5: 8.1 which i'd have expected, ppracer is quite CPU-intense on my test-system, and the fairness model of SD and CFS is similar for CPU-bound tasks. But ... numbers from _me_ are suspect by definition, i wrote a good chunk of the CFS code :-) So it would be much more interesting if others provided more numbers. Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. then create load the following way, by entering this into a shell: while :; do :; done that will cause a shell to just loop infinitely, hogging the CPU. This is the 1 loop case in the numbers i posted. Start several of them to get more. (Type 'killall bash' in the same terminal to get rid of them.) Monitor how the FPS of your game changes when you start more and more CPU hogs, and note the numbers. Repeat it under SD and CFS as well, and please post the results into this thread. and note that CPU hogs are just one type of 'load' that a system can experience - IO load or networking load could impact your in-game experience just as much. If you see any artifact or FPS reduction under CFS i'll give you further info about how to debug it (were you interested in debugging it). Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Mon, 30 Jul 2007, Ingo Molnar wrote: * John [EMAIL PROTECTED] wrote: On 7/29/07, Ingo Molnar [EMAIL PROTECTED] wrote: * John [EMAIL PROTECTED] wrote: Ingo- Why not perform the same test using the native linux Q3 client to compare numbers to wine? [...] I regularly test native Linux games on CFS, and they all behave well. While waiting for more detailed data from Kasper i was looking for atypical stuff in Kasper's description about what his workload involves, and what looked a bit atypical was that Kasper's workload also involved gaming under Wine: I understand that, I was just wondering if the FPS scales the same natively vs. Wine as I typically only run native games. [...] people are regularly testing 3D smoothness, and they find CFS good enough: http://bhhdoa.org.au/pipermail/ck/2007-June/007816.html and that matches my experience as well (as limited as it may be). In general my impression is that CFS and SD are roughly on par when it comes to 3D smoothness. SNIP i have no numbers now, other than the trivial native 'ppracer' game where SD and CFS have roughly the same framerate under load: SD CFS SNIP which i'd have expected, ppracer is quite CPU-intense on my test-system, and the fairness model of SD and CFS is similar for CPU-bound tasks. But ... numbers from _me_ are suspect by definition, i wrote a good chunk of the CFS code :-) So it would be much more interesting if others provided more numbers. Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. the one report that I saw said that the FPS numbers were overall the same, but what the reporter was seeing was that CFS was doing it in bursts of activity while SD was smoother. this wasn't enough to show up in the fps numbers being reported, but was enough to be unreasonable for gameing. IIRC Linus responded with thoughts on granularity and the fact that changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 10x (which could be enough to trigger this sort of issue) David Lang - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Jacob Braun [EMAIL PROTECTED] wrote: On 7/30/07, kriko [EMAIL PROTECTED] wrote: I would try the new cfs how it performs, but it seems that nvidia drivers doesn't compile successfully under 2.6.23-rc1. http://files.myopera.com/kriko/files/nvidia-installer.log If someone has the solution, please share. There is a patch for the nvidia drivers here: http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky [EMAIL PROTECTED] Bad call on the nobody was using these, Martin :( -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Segunda, 30 de Julho de 2007 12:46, Ingo Molnar escreveu: * John [EMAIL PROTECTED] wrote: On 7/29/07, Ingo Molnar [EMAIL PROTECTED] wrote: * John [EMAIL PROTECTED] wrote: Ingo- Why not perform the same test using the native linux Q3 client to compare numbers to wine? [...] [...] and that matches my experience as well (as limited as it may be). In general my impression is that CFS and SD are roughly on par when it comes to 3D smoothness. The Wine+Quake3 numbers i posted yesterday are so bad under SD that they must be some artifact in SD (possibly related to yield - i've strace-ed the tasks under SD today and they are blocking in yield), so they are not really representative of the general quality of SD (unless you are being hit by that particular regression). Still it is kind of ironic that when i tried to find a 3D regression in CFS i found a 3D regression in SD. I also tryied Q3A demo and i got similar values to yours: CFS 90 2.6.22 90 SD 90 while running that endless loop, on 2.6.22 and SD it drops instantly to 4 fps. While CFS runs ~70 with 1.9 load. I was able to play the game without noticing much degradation. I written these values while playing under CFS: load fps 1.6681 1.7375 1.9770s With this patch [1] someone sent me over IRC i get similar values to CFS, maybe a few fps more, but thats insignificant and not very accurate to measure. Anyway with this patch i am playing with a load of 2.2 at ~75 fps, 1024x768 windowed. It's enjoyable to frag the dumb 'Major' as under CFS. I think the main difference in performance of CFS and SD it's the implementation of sched_yield (which is used by graphic drivers) and CFS has changed the implementation of sched_yield. You use: in mainline (2.6.22): /** * sys_sched_yield - yield the current processor to other threads. * * This function yields the current CPU by moving the calling thread * to the expired array. If there are no other threads running on this * CPU then this function will return. */ you changed it to something like: if (unlikely(rq-nr_running == 1)) schedstat_inc(rq, yld_act_empty); else current-sched_class-yield_task(rq, current); wile mainline (2.6.22) and SD use: dequeue_task(current, array); enqueue_task(current, target); and requeue_task() Anyway i am going to continue to frag a bit more :) [1] - http://rafb.net/p/Rbpqaz26.html There are 2 modes for this hack: sysctl kernel.sched_yield = 1 or 2, see patch. [...] Ingo ___ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: [EMAIL PROTECTED] http://vds.kolivas.org/mailman/listinfo/ck -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote: On 7/31/07, Jacob Braun [EMAIL PROTECTED] wrote: On 7/30/07, kriko [EMAIL PROTECTED] wrote: I would try the new cfs how it performs, but it seems that nvidia drivers doesn't compile successfully under 2.6.23-rc1. http://files.myopera.com/kriko/files/nvidia-installer.log If someone has the solution, please share. There is a patch for the nvidia drivers here: http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky [EMAIL PROTECTED] Bad call on the nobody was using these, Martin :( Do we care ? The code should be replaced with ptep_get_and_clear + pte_modify anyway.. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote: On 7/31/07, Jacob Braun [EMAIL PROTECTED] wrote: On 7/30/07, kriko [EMAIL PROTECTED] wrote: I would try the new cfs how it performs, but it seems that nvidia drivers doesn't compile successfully under 2.6.23-rc1. http://files.myopera.com/kriko/files/nvidia-installer.log If someone has the solution, please share. There is a patch for the nvidia drivers here: http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky [EMAIL PROTECTED] Bad call on the nobody was using these, Martin :( Nobody in the upstream kernel did, and that is what matters. If you care about your kernel code get it upstream. As for breaking binary crap, thats a bonus. Break them hard, break them often. Kudos to Martin. - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Martin Schwidefsky wrote: Do we care ? The code should be replaced with ptep_get_and_clear + pte_modify anyway.. Since the general direction of this thread was for people to test 3D game performance with the shiny new CFS cpu scheduler, I would say yes, we do care if people with the only 2 types of gaming caliber Video cards can get said video cards working, right now, with said shiny new kernel. Yes yes, I know, kernel devs don't care if they break binary drivers... and in principle, I agree with that philosophy.. but it's still damn inconvenient at times :) - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
As for breaking binary crap, thats a bonus. Break them hard, break them often. I think there's a big difference in philosophy between break binary drivers if you want to make a legitimate change for whatever reason and break binary drivers just to be a pain in the ass to the developers and users of said drivers. I think most people here agree with the first. It's unclear to me how many here agree with the second, but I know it's at least one. ;-) Kyle - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 02:25 +1000, Matthew Hawkins wrote: On 7/31/07, Jacob Braun [EMAIL PROTECTED] wrote: On 7/30/07, kriko [EMAIL PROTECTED] wrote: I would try the new cfs how it performs, but it seems that nvidia drivers doesn't compile successfully under 2.6.23-rc1. http://files.myopera.com/kriko/files/nvidia-installer.log If someone has the solution, please share. There is a patch for the nvidia drivers here: http://bugs.gentoo.org/attachment.cgi?id=125959 The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky [EMAIL PROTECTED] some fo these binary drivers do really really bad stuff (esp the AMD ones are infamous for that) and it's no surprise they might throw of a new scheduler. In fact, that's a bonus, some of those hacks are workarounds for older (often 2.4) scheduler corner cases and should just be removed from the driver to get better performance. Holding back linux for such hacky junk in binary drivers would be the absolute worst thing to do; even for people who insist on using these drivers over the open source ones, since the next rev of these drivers can now use the new scheduler and actually be faster with all the workarounds removed. Very likely the best thing to do is to contact the supplier of the driver (AMD or Nvidia) and ask them to fix it. - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Ingo Molnar wrote: large snip Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? -- Kenneth Prugh signature.asc Description: OpenPGP digital signature
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, Jul 31, 2007 at 02:25:47AM +1000, Matthew Hawkins wrote: The ATI drivers (current 8.39.4) were broken by commit e21ea246bce5bb93dd822de420172ec280aed492 Author: Martin Schwidefsky [EMAIL PROTECTED] Bad call on the nobody was using these, Martin :( Sorry to use foul language once again after a while, but: Fuck you Martin! not only is complaining about illegal binary crap totally offtopic on this list, and making youself a fool for using that piece of shit is annoying enough, but don't even try to badmouth Martin for doing important and needed cleanups. And now get out of here! - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Miguel Figueiredo [EMAIL PROTECTED] wrote:
in mainline (2.6.22):
/**
* sys_sched_yield - yield the current processor to other threads.
*
* This function yields the current CPU by moving the calling thread
* to the expired array. If there are no other threads running on this
* CPU then this function will return.
*/
you changed it to something like:
if (unlikely(rq-nr_running == 1))
schedstat_inc(rq, yld_act_empty);
else
current-sched_class-yield_task(rq, current);
wile mainline (2.6.22) and SD use:
dequeue_task(current, array);
enqueue_task(current, target);
this is what CFS does:
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
u64 now = __rq_clock(rq);
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, p-se, 0, now);
enqueue_entity(cfs_rq, p-se, 0, now);
}
Ingo
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. the one report that I saw said that the FPS numbers were overall the same, but what the reporter was seeing was that CFS was doing it in bursts of activity while SD was smoother. [...] which report is that, precisely? I'm not aware of any such report past CFS v14 or so. IIRC Linus responded with thoughts on granularity and the fact that changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 10x (which could be enough to trigger this sort of issue) ah, you mean Kasper Sandberg's report? That turned out to be based on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests, and if there's still any regression left we'll fix it. Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Mon, 30 Jul 2007, Ingo Molnar wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Would you be interested in trying CFS and doing some numers perhaps? It requires some work: you have to start up your favorite game in a way that gives a reliable framerate number. (many games allow the display of FPS in-game) In Quake3 i simply started the game and did not move the player - that is something easy to reproduce. the one report that I saw said that the FPS numbers were overall the same, but what the reporter was seeing was that CFS was doing it in bursts of activity while SD was smoother. [...] which report is that, precisely? I'm not aware of any such report past CFS v14 or so. IIRC Linus responded with thoughts on granularity and the fact that changing from Hz 1000 to Hz 100 will increase the timeslices in CFS by 10x (which could be enough to trigger this sort of issue) ah, you mean Kasper Sandberg's report? That turned out to be based on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests, and if there's still any regression left we'll fix it. probably. I delete lkml messages pretty agressivly so I don't have them around to refer to. David Lang - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ah, you mean Kasper Sandberg's report? That turned out to be based on an older CFS version, not v2.6.23-rc1. Kasper said he'll redo his tests, and if there's still any regression left we'll fix it. probably. I delete lkml messages pretty agressivly so I don't have them around to refer to. lkml.org is your friend: http://lkml.org/lkml/2007/7/27/423 http://lkml.org/lkml/2007/7/28/50 http://lkml.org/lkml/2007/7/30/195 :-) Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kenneth Prugh [EMAIL PROTECTED] wrote: Ingo Molnar wrote: large snip Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? .22-ck1 includes it, so that should be fine: http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Segunda, 30 de Julho de 2007 19:38, Ingo Molnar escreveu:
* Miguel Figueiredo [EMAIL PROTECTED] wrote:
in mainline (2.6.22):
/**
* sys_sched_yield - yield the current processor to other threads.
*
* This function yields the current CPU by moving the calling thread
* to the expired array. If there are no other threads running on this
* CPU then this function will return.
*/
[...]
this is what CFS does:
static void yield_task_fair(struct rq *rq, struct task_struct *p)
{
struct cfs_rq *cfs_rq = task_cfs_rq(p);
u64 now = __rq_clock(rq);
/*
* Dequeue and enqueue the task to update its
* position within the tree:
*/
dequeue_entity(cfs_rq, p-se, 0, now);
enqueue_entity(cfs_rq, p-se, 0, now);
}
Ingo
So the difference from mainline (2.6.22) is that now you removed
requeue_task(), is that it?
--
Com os melhores cumprimentos/Best regards,
Miguel Figueiredo
http://www.DebianPT.org
-
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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Ingo Molnar wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: Ingo Molnar wrote: large snip Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? .22-ck1 includes it, so that should be fine: http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html Ingo Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map while not moving at all and always facing the same direction, while slowing increasing the number of loops. CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. Below you will find the results of my test with the average number of FPS. CFS | SD UT2004 + 0 loops | 200 FPS UT2004 + 0 loops | 190 FPS UT2004 + 1 loops | 195 FPS UT2004 + 1 loops | 190 FPS UT2004 + 2 loops | 190 FPS UT2004 + 2 loops | 190 FPS UT2004 + 3 loops | 189 FPS UT2004 + 3 loops | 136 FPS UT2004 + 4 loops | 150 FPS UT2004 + 4 loops | 137 FPS UT2004 + 5 loops | 145 FPS UT2004 + 5 loops | 136 FPS UT2004 + 6 loops | 145 FPS UT2004 + 6 loops | 105 FPS UT2004 + 7 loops | 118 FPS UT2004 + 7 loops | 104 FPS UT2004 + 8 loops | 97 FPS UT2004 + 8 loops | 104 FPS UT2004 + 9 loops | 94 FPS UT2004 + 9 loops | 89 FPS UT2004 + 10 loops | 92 FPS UT2004 + 10 loops | 91 FPS -- Kenneth Prugh signature.asc Description: OpenPGP digital signature
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Em Segunda, 30 de Julho de 2007 22:24, Kenneth Prugh escreveu: Ingo Molnar wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: Ingo Molnar wrote: large snip Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? .22-ck1 includes it, so that should be fine: http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html Ingo Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map while not moving at all and always facing the same direction, while slowing increasing the number of loops. CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. Below you will find the results of my test with the average number of FPS. CFS | SD UT2004 + 0 loops | 200 FPSUT2004 + 0 loops | 190 FPS UT2004 + 1 loops | 195 FPSUT2004 + 1 loops | 190 FPS UT2004 + 2 loops | 190 FPSUT2004 + 2 loops | 190 FPS UT2004 + 3 loops | 189 FPSUT2004 + 3 loops | 136 FPS UT2004 + 4 loops | 150 FPSUT2004 + 4 loops | 137 FPS UT2004 + 5 loops | 145 FPSUT2004 + 5 loops | 136 FPS UT2004 + 6 loops | 145 FPSUT2004 + 6 loops | 105 FPS UT2004 + 7 loops | 118 FPSUT2004 + 7 loops | 104 FPS UT2004 + 8 loops | 97 FPS UT2004 + 8 loops | 104 FPS UT2004 + 9 loops | 94 FPS UT2004 + 9 loops | 89 FPS UT2004 + 10 loops | 92 FPSUT2004 + 10 loops | 91 FPS can you apply the patch [1] that changes the behaviour of sched_yield on SD and report the results? SD should scale a lot better after the patch. 1 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html -- Com os melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Miguel Figueiredo wrote: Em Segunda, 30 de Julho de 2007 22:24, Kenneth Prugh escreveu: Ingo Molnar wrote: * Kenneth Prugh [EMAIL PROTECTED] wrote: Ingo Molnar wrote: large snip Hello, I have a gaming rig and would love to help benchmark with my copy of UT2004(E6600 Core2 and a 7950GTO card). Or if you have anything else that would better serve as a benchmark I could grab it and try. The only problem is I don't know what 2 kernels I should be using to test the schedulers. I assume 2.6.23-rc1 for CFS, but what about SD? .22-ck1 includes it, so that should be fine: http://ussg.iu.edu/hypermail/linux/kernel/0707.1/0318.html Ingo Alright, Just got done with some testing of UT2004 between 2.6.23-rc1 CFS and 2.6.22-ck1 SD. This series of tests was run by spawning in a map while not moving at all and always facing the same direction, while slowing increasing the number of loops. CFS generally seemed a lot smoother as the load increased, while SD broke down to a highly unstable fps count that fluctuated massively around the third loop. Seems like I will stick to CFS for gaming now. Below you will find the results of my test with the average number of FPS. CFS | SD UT2004 + 0 loops | 200 FPS UT2004 + 0 loops | 190 FPS UT2004 + 1 loops | 195 FPS UT2004 + 1 loops | 190 FPS UT2004 + 2 loops | 190 FPS UT2004 + 2 loops | 190 FPS UT2004 + 3 loops | 189 FPS UT2004 + 3 loops | 136 FPS UT2004 + 4 loops | 150 FPS UT2004 + 4 loops | 137 FPS UT2004 + 5 loops | 145 FPS UT2004 + 5 loops | 136 FPS UT2004 + 6 loops | 145 FPS UT2004 + 6 loops | 105 FPS UT2004 + 7 loops | 118 FPS UT2004 + 7 loops | 104 FPS UT2004 + 8 loops | 97 FPSUT2004 + 8 loops | 104 FPS UT2004 + 9 loops | 94 FPSUT2004 + 9 loops | 89 FPS UT2004 + 10 loops | 92 FPS UT2004 + 10 loops | 91 FPS can you apply the patch [1] that changes the behaviour of sched_yield on SD and report the results? SD should scale a lot better after the patch. 1 - http://bhhdoa.org.au/pipermail/ck/2007-July/008297.html I Applied the patch. SD Seemed a bit smoother over the loads, although that could be a placebo effect. It wasn't until the 8 or 9th loop running that I could really notice that the fps were fluctuating in the map without looking at the fps counter. SD-Patched UT2004 + 0 loops | 202 FPS UT2004 + 1 loops | 201 FPS UT2004 + 2 loops | 199 FPS UT2004 + 3 loops | 143 FPS UT2004 + 4 loops | 145 FPS UT2004 + 5 loops | 145 FPS UT2004 + 6 loops | 112 FPS UT2004 + 7 loops | 110 FPS UT2004 + 8 loops | 108 FPS UT2004 + 9 loops | 90 FPS UT2004 + 10 loops | 89 FPS -- Kenneth Prugh - Ken69267 Gentoo AMD64 Arch Tester signature.asc Description: OpenPGP digital signature
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/30/07, John <[EMAIL PROTECTED]> wrote: > I understand that, I was just wondering if the FPS scales the same natively > vs. Wine as I typically only run native games. I have been hesitant to move > over to CFS due to reports of 3D issues and wanted to see if you had numbers > in regards to CFS vs. SD. John, the numbers Ingo makes and the numbers you make will no doubt be different (unless by some fantastic freak of nature you both have identical systems). Take this opportunity to do this testing yourself so in case there is some improvement to make, it can be done for 2.6.23. Nobody can benchmark your system but you. Remember to set CONFIG_HZ to 1000 -- Matt - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* John <[EMAIL PROTECTED]> wrote: > Ingo- > > Why not perform the same test using the native linux Q3 client to > compare numbers to wine? [...] I regularly test native Linux games on CFS, and they all behave well. While waiting for more detailed data from Kasper i was looking for atypical stuff in Kasper's description about what his workload involves, and what looked a bit atypical was that Kasper's workload also involved gaming under Wine: > > > my test subjects are quake(s), world of warcraft via wine, unreal > > > tournament 2004. [...] and Wine is a more complex server/client scenario instead of a single (and simple) standalone Quake3 binary that the Linux binary does. So it looked more interesting from a scheduler workload (and scheduler regression) POV. In any case i'll need more info from Kasper. Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* John [EMAIL PROTECTED] wrote: Ingo- Why not perform the same test using the native linux Q3 client to compare numbers to wine? [...] I regularly test native Linux games on CFS, and they all behave well. While waiting for more detailed data from Kasper i was looking for atypical stuff in Kasper's description about what his workload involves, and what looked a bit atypical was that Kasper's workload also involved gaming under Wine: my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. [...] and Wine is a more complex server/client scenario instead of a single (and simple) standalone Quake3 binary that the Linux binary does. So it looked more interesting from a scheduler workload (and scheduler regression) POV. In any case i'll need more info from Kasper. Ingo - 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/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/30/07, John [EMAIL PROTECTED] wrote: I understand that, I was just wondering if the FPS scales the same natively vs. Wine as I typically only run native games. I have been hesitant to move over to CFS due to reports of 3D issues and wanted to see if you had numbers in regards to CFS vs. SD. John, the numbers Ingo makes and the numbers you make will no doubt be different (unless by some fantastic freak of nature you both have identical systems). Take this opportunity to do this testing yourself so in case there is some improvement to make, it can be done for 2.6.23. Nobody can benchmark your system but you. Remember to set CONFIG_HZ to 1000 -- Matt - 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/
