Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > do you have any filesystem that is not reiserfs? If yes, could you, as > a test, check whether file activities on _that_ file system still > cause these lags, or is the lag purely connected to the reiser3 > filesystem? i still have little debug info from you to start from: no cfs-debug-info.sh output of the problematic workload and no kernel .config. i tried to reproduce your problems based on your existing description: i did a lot of reiser3 testing yesterday and i also wrote a 'BKL latency simulator' (which does a faux lock_kernel() + unlock_kernel() so that the testcode runs into the BKL all the time) - but still this had no visible effect on desktop latencies so either i have some subtle difference in my setup or this aspect of your workload is not the cause of the smoothness problem. could please give us more debug info and try to simplify the "bad" case down to something that can be pinpointed and triggered more exactly? Do you see any particular 'ruckle' in the 3D game when you see a smoothness problem? Anything that we could clearly label as 'anomalous latency' in a tracer output? (in that case i'll send you tracing patches so that we can catch a trace of that 'hickup') You said the imap stuff could be causing the smoothness problem: as a debugging thing could you try to renice all the imap activities (imap daemon / mailer) to nice +19, does that make the game magically smooth again? If yes then this is an indicator that the problem is interaction between the game and the imap activities. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Ingo Molnar [EMAIL PROTECTED] wrote: do you have any filesystem that is not reiserfs? If yes, could you, as a test, check whether file activities on _that_ file system still cause these lags, or is the lag purely connected to the reiser3 filesystem? i still have little debug info from you to start from: no cfs-debug-info.sh output of the problematic workload and no kernel .config. i tried to reproduce your problems based on your existing description: i did a lot of reiser3 testing yesterday and i also wrote a 'BKL latency simulator' (which does a faux lock_kernel() + unlock_kernel() so that the testcode runs into the BKL all the time) - but still this had no visible effect on desktop latencies so either i have some subtle difference in my setup or this aspect of your workload is not the cause of the smoothness problem. could please give us more debug info and try to simplify the bad case down to something that can be pinpointed and triggered more exactly? Do you see any particular 'ruckle' in the 3D game when you see a smoothness problem? Anything that we could clearly label as 'anomalous latency' in a tracer output? (in that case i'll send you tracing patches so that we can catch a trace of that 'hickup') You said the imap stuff could be causing the smoothness problem: as a debugging thing could you try to renice all the imap activities (imap daemon / mailer) to nice +19, does that make the game magically smooth again? If yes then this is an indicator that the problem is interaction between the game and the imap activities. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Kasper, could you please try the "chew-max" latency-printing utility: http://people.redhat.com/mingo/cfs-scheduler/tools/chew-max.c if you start it on an idle system it prints a single line: $ ./chew-max pid 14506, prio 0, interval of 99984800 nsec and prints nothing else. It continues looping and looping (using up 100% of CPU time), and the moment it's preempted, it prints a line about that preemption latency. Under higher load it will print something like this: out for 63 ms [max: 66], ran for5 ms, load 7 out for 85 ms [max: 85], ran for4 ms, load 5 out for7 ms [max: 85], ran for0 ms, load 0 out for 105 ms [max: 105], ran for3 ms, load 3 out for 174 ms [max: 174], ran for6 ms, load 3 out for 219 ms [max: 219], ran for3 ms, load 1 out for 78 ms [max: 219], ran for3 ms, load 3 so that we get a picture of your latencies, could you run this tool why you are seeing those 'bad' desktop latencies? (Since your CPU has two cores it might make sense to run two instances of chew-max.) record the latencies like this: ./chew-max > chew1.out & ./chew-max > chew2.out & and send us the chew1.out and chew2.out files (bzip2 -9 compressed). Thanks! 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Thu, 2007-08-02 at 13:45 +0200, Ingo Molnar wrote: > * Lee Revell <[EMAIL PROTECTED]> wrote: > > > On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > Almost all of the Reiser3 > > > code runs under the BKL, and the only other major kernel infrastructure > > > that has BKL dependencies is the TTY code. > > > > Also NFS: > > > > $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l > > 94 > > yeah - but i never saw NFS cause really big BKL latencies. IIRC it uses > the BKL mostly for archaic reasons, most of the NFS code is SMP-safe. > Almost all of the reiser3 code runs under the BKL on the other hand. We're still working on fixing the NFS case, but as everyone knows, finding those last few obscure code sections which still depend on BKL protection can be tedious work... Trond - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Wed, Aug 01, 2007 at 10:35:41PM -0400, Lee Revell wrote: > On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > Almost all of the Reiser3 > > code runs under the BKL, and the only other major kernel infrastructure > > that has BKL dependencies is the TTY code. > > Also NFS: > > $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l > 94 All the file locking code (the nfs-related stuff in fs/lockd/, and also the vfs code in fs/locks.c) is under the kernel lock. I doubt it's held very long unless you have ridiculous numbers of processes requesting locks on the same file, but I don't know. --b. - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > ah, indeed, that makes quite a bit of sense. Almost all of the > > Reiser3 code runs under the BKL, and the only other major kernel > > infrastructure that has BKL dependencies is the TTY code. Kasper, as > > a debugging matter, could you try to move that spamassassin workload > > off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If > > that makes a noticeable difference (for the better ;) then we can > > continue figuring out what's happening exactly. > > the pricess is as this: > mail client fetches mail > mail client invokes spamasassin > if spam -> spam > else filtering > if it matches certain filters, it gets put into my imap server, which is > reiserfs. do you have any filesystem that is not reiserfs? If yes, could you, as a test, check whether file activities on _that_ file system still cause these lags, or is the lag purely connected to the reiser3 filesystem? 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Lee Revell <[EMAIL PROTECTED]> wrote: > On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > Almost all of the Reiser3 > > code runs under the BKL, and the only other major kernel infrastructure > > that has BKL dependencies is the TTY code. > > Also NFS: > > $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l > 94 yeah - but i never saw NFS cause really big BKL latencies. IIRC it uses the BKL mostly for archaic reasons, most of the NFS code is SMP-safe. Almost all of the reiser3 code runs under the BKL on the other hand. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Lee Revell [EMAIL PROTECTED] wrote: On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Also NFS: $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l 94 yeah - but i never saw NFS cause really big BKL latencies. IIRC it uses the BKL mostly for archaic reasons, most of the NFS code is SMP-safe. Almost all of the reiser3 code runs under the BKL on the other hand. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kasper Sandberg [EMAIL PROTECTED] wrote: ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging matter, could you try to move that spamassassin workload off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a noticeable difference (for the better ;) then we can continue figuring out what's happening exactly. the pricess is as this: mail client fetches mail mail client invokes spamasassin if spam - spam else filtering if it matches certain filters, it gets put into my imap server, which is reiserfs. do you have any filesystem that is not reiserfs? If yes, could you, as a test, check whether file activities on _that_ file system still cause these lags, or is the lag purely connected to the reiser3 filesystem? 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Wed, Aug 01, 2007 at 10:35:41PM -0400, Lee Revell wrote: On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Also NFS: $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l 94 All the file locking code (the nfs-related stuff in fs/lockd/, and also the vfs code in fs/locks.c) is under the kernel lock. I doubt it's held very long unless you have ridiculous numbers of processes requesting locks on the same file, but I don't know. --b. - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Thu, 2007-08-02 at 13:45 +0200, Ingo Molnar wrote: * Lee Revell [EMAIL PROTECTED] wrote: On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Also NFS: $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l 94 yeah - but i never saw NFS cause really big BKL latencies. IIRC it uses the BKL mostly for archaic reasons, most of the NFS code is SMP-safe. Almost all of the reiser3 code runs under the BKL on the other hand. We're still working on fixing the NFS case, but as everyone knows, finding those last few obscure code sections which still depend on BKL protection can be tedious work... Trond - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Kasper, could you please try the chew-max latency-printing utility: http://people.redhat.com/mingo/cfs-scheduler/tools/chew-max.c if you start it on an idle system it prints a single line: $ ./chew-max pid 14506, prio 0, interval of 99984800 nsec and prints nothing else. It continues looping and looping (using up 100% of CPU time), and the moment it's preempted, it prints a line about that preemption latency. Under higher load it will print something like this: out for 63 ms [max: 66], ran for5 ms, load 7 out for 85 ms [max: 85], ran for4 ms, load 5 out for7 ms [max: 85], ran for0 ms, load 0 out for 105 ms [max: 105], ran for3 ms, load 3 out for 174 ms [max: 174], ran for6 ms, load 3 out for 219 ms [max: 219], ran for3 ms, load 1 out for 78 ms [max: 219], ran for3 ms, load 3 so that we get a picture of your latencies, could you run this tool why you are seeing those 'bad' desktop latencies? (Since your CPU has two cores it might make sense to run two instances of chew-max.) record the latencies like this: ./chew-max chew1.out ./chew-max chew2.out and send us the chew1.out and chew2.out files (bzip2 -9 compressed). Thanks! 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > Almost all of the Reiser3 > code runs under the BKL, and the only other major kernel infrastructure > that has BKL dependencies is the TTY code. Also NFS: $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l 94 Lee - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 10:57 +0200, Ingo Molnar wrote: > * Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: > > > > > could perhaps be filesystem related, i have my maildir(extremely > > > large) on reiserfs, and /home on xfs. what my mail client will do is > > > download mail, spamasassin it(loading database from home), then it > > > will put to imap server placing it on reiserfs, and then a "local" > > > copy in my home. > > > > Ooh, do you perchance have PREEMPT_BKL=y? > > sorry late response. nope, i run totally without preemption, i did however test with, it seemed to not matter in terms of smoothness, but reduced the throughput slightly. > > If so, try on another filesystem than reiserfs (or disable > > PREEMPT_BKL, but that is obviously the lesser of the two choices). > > > > Ingo traced a 1+ second latency at my end to BKL priority inversion > > between tty and reiserfs. > > ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 > code runs under the BKL, and the only other major kernel infrastructure > that has BKL dependencies is the TTY code. Kasper, as a debugging > matter, could you try to move that spamassassin workload off into a > non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a > noticeable difference (for the better ;) then we can continue figuring > out what's happening exactly. the pricess is as this: mail client fetches mail mail client invokes spamasassin if spam -> spam else filtering if it matches certain filters, it gets put into my imap server, which is reiserfs. > 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 10:57 +0200, Ingo Molnar wrote: * Peter Zijlstra [EMAIL PROTECTED] wrote: On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a local copy in my home. Ooh, do you perchance have PREEMPT_BKL=y? sorry late response. nope, i run totally without preemption, i did however test with, it seemed to not matter in terms of smoothness, but reduced the throughput slightly. If so, try on another filesystem than reiserfs (or disable PREEMPT_BKL, but that is obviously the lesser of the two choices). Ingo traced a 1+ second latency at my end to BKL priority inversion between tty and reiserfs. ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging matter, could you try to move that spamassassin workload off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a noticeable difference (for the better ;) then we can continue figuring out what's happening exactly. the pricess is as this: mail client fetches mail mail client invokes spamasassin if spam - spam else filtering if it matches certain filters, it gets put into my imap server, which is reiserfs. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On 7/31/07, Ingo Molnar [EMAIL PROTECTED] wrote: Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Also NFS: $ grep -rIi lock_kernel kernel-source/linux-2.6.17/fs/nfs/ | wc -l 94 Lee - 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)
* 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
> > oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of > > the very few pieces of kernel code that scares the hell out of me :-) I'm not too fond of the way it does some stuff either especially the open v close v hangup paths but that is partly the fault of POSIX 8) > Maybe it should be kept crufty then. Every kernel developer should have > at least one part of the kernel he's afraid to go into ;-) floppy.c is sufficient - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Ingo Molnar wrote: For the tty layer I'm waiting for the revoke code to get finished up and move from -mm into Linus tree. At that point the real evil lock_kernel related stuff in the tty layer can switch to using the revoke code for hangup paths and then other bits can be tackled. oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of the very few pieces of kernel code that scares the hell out of me :-) Maybe it should be kept crufty then. Every kernel developer should have at least one part of the kernel he's afraid to go into ;-) -- error compiling committee.c: too many arguments to function - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Alan Cox <[EMAIL PROTECTED]> wrote: > > code runs under the BKL, and the only other major kernel > > infrastructure that has BKL dependencies is the TTY code. Kasper, as > > a debugging > > And half the ioctls some of which trigger long code sections. the tty layer has relatively short BKL latencies, but reiser3 has long ones, so those got transposed over to the tty layer, making it all quite noticeable to the user. BKL contention is not a big issue on the desktop _unless_ there's at least one workload that creates really long BKL latencies. That multiplexes it out to all the other BKL-using subsystems too. the DRI/DRM BKL use was a problem some time ago, but i think it's now using unlocked_ioctl(), correct? All the other ioctls are rare enough to not really matter. with PREEMPT_BKL there's also some sort of random effect of priority inversion that makes the actual latencies depend on the scheduler - but we dont understand that effect exactly, yet. (hopefully Kasper can help us out with that. Peter got rid of his reiser3 partition the moment the latencies were traced back to it.) > For the tty layer I'm waiting for the revoke code to get finished up > and move from -mm into Linus tree. At that point the real evil > lock_kernel related stuff in the tty layer can switch to using the > revoke code for hangup paths and then other bits can be tackled. oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of the very few pieces of kernel code that scares the hell out of me :-) 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
> code runs under the BKL, and the only other major kernel infrastructure > that has BKL dependencies is the TTY code. Kasper, as a debugging And half the ioctls some of which trigger long code sections. For the tty layer I'm waiting for the revoke code to get finished up and move from -mm into Linus tree. At that point the real evil lock_kernel related stuff in the tty layer can switch to using the revoke code for hangup paths and then other bits can be tackled. Alan - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Peter Zijlstra <[EMAIL PROTECTED]> wrote: > On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: > > > could perhaps be filesystem related, i have my maildir(extremely > > large) on reiserfs, and /home on xfs. what my mail client will do is > > download mail, spamasassin it(loading database from home), then it > > will put to imap server placing it on reiserfs, and then a "local" > > copy in my home. > > Ooh, do you perchance have PREEMPT_BKL=y? > > If so, try on another filesystem than reiserfs (or disable > PREEMPT_BKL, but that is obviously the lesser of the two choices). > > Ingo traced a 1+ second latency at my end to BKL priority inversion > between tty and reiserfs. ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging matter, could you try to move that spamassassin workload off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a noticeable difference (for the better ;) then we can continue figuring out what's happening exactly. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: > could perhaps be filesystem related, i have my maildir(extremely large) > on reiserfs, and /home on xfs. what my mail client will do is download > mail, spamasassin it(loading database from home), then it will put to > imap server placing it on reiserfs, and then a "local" copy in my home. Ooh, do you perchance have PREEMPT_BKL=y? If so, try on another filesystem than reiserfs (or disable PREEMPT_BKL, but that is obviously the lesser of the two choices). Ingo traced a 1+ second latency at my end to BKL priority inversion between tty and reiserfs. - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a local copy in my home. Ooh, do you perchance have PREEMPT_BKL=y? If so, try on another filesystem than reiserfs (or disable PREEMPT_BKL, but that is obviously the lesser of the two choices). Ingo traced a 1+ second latency at my end to BKL priority inversion between tty and reiserfs. - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Peter Zijlstra [EMAIL PROTECTED] wrote: On Tue, 2007-07-31 at 01:46 +0200, Kasper Sandberg wrote: could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a local copy in my home. Ooh, do you perchance have PREEMPT_BKL=y? If so, try on another filesystem than reiserfs (or disable PREEMPT_BKL, but that is obviously the lesser of the two choices). Ingo traced a 1+ second latency at my end to BKL priority inversion between tty and reiserfs. ah, indeed, that makes quite a bit of sense. Almost all of the Reiser3 code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging matter, could you try to move that spamassassin workload off into a non-Reiser3 filesystem and/or disable PREEMPT_BKL? If that makes a noticeable difference (for the better ;) then we can continue figuring out what's happening exactly. 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging And half the ioctls some of which trigger long code sections. For the tty layer I'm waiting for the revoke code to get finished up and move from -mm into Linus tree. At that point the real evil lock_kernel related stuff in the tty layer can switch to using the revoke code for hangup paths and then other bits can be tackled. Alan - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Alan Cox [EMAIL PROTECTED] wrote: code runs under the BKL, and the only other major kernel infrastructure that has BKL dependencies is the TTY code. Kasper, as a debugging And half the ioctls some of which trigger long code sections. the tty layer has relatively short BKL latencies, but reiser3 has long ones, so those got transposed over to the tty layer, making it all quite noticeable to the user. BKL contention is not a big issue on the desktop _unless_ there's at least one workload that creates really long BKL latencies. That multiplexes it out to all the other BKL-using subsystems too. the DRI/DRM BKL use was a problem some time ago, but i think it's now using unlocked_ioctl(), correct? All the other ioctls are rare enough to not really matter. with PREEMPT_BKL there's also some sort of random effect of priority inversion that makes the actual latencies depend on the scheduler - but we dont understand that effect exactly, yet. (hopefully Kasper can help us out with that. Peter got rid of his reiser3 partition the moment the latencies were traced back to it.) For the tty layer I'm waiting for the revoke code to get finished up and move from -mm into Linus tree. At that point the real evil lock_kernel related stuff in the tty layer can switch to using the revoke code for hangup paths and then other bits can be tackled. oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of the very few pieces of kernel code that scares the hell out of me :-) 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
Ingo Molnar wrote: For the tty layer I'm waiting for the revoke code to get finished up and move from -mm into Linus tree. At that point the real evil lock_kernel related stuff in the tty layer can switch to using the revoke code for hangup paths and then other bits can be tackled. oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of the very few pieces of kernel code that scares the hell out of me :-) Maybe it should be kept crufty then. Every kernel developer should have at least one part of the kernel he's afraid to go into ;-) -- error compiling committee.c: too many arguments to function - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
oh, wonderful! Alan, you are a true wizard :-) The tty layer is one of the very few pieces of kernel code that scares the hell out of me :-) I'm not too fond of the way it does some stuff either especially the open v close v hangup paths but that is partly the fault of POSIX 8) Maybe it should be kept crufty then. Every kernel developer should have at least one part of the kernel he's afraid to go into ;-) floppy.c is sufficient - 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Sun, 2007-07-29 at 19:06 +0200, Ingo Molnar wrote: > * Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > Im still not so keen about this, Ingo never did get CFS to match SD in > > smoothness for 3d applications, where my test subjects are quake(s), > > world of warcraft via wine, unreal tournament 2004. [...] > > here's an update: checking whether Wine could be a factor in your > problem i just tested latest CFS against latest SD with a 3D game > running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the > most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). > Here are the results in a pretty graph: > >http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg > > or, in text: > > 2.6.22-ck1 2.6.22-cfs-v19 > >quake + 0 loops | 41 fpsquake + 0 loops | 41 fps >quake + 1 loop | 3 fpsquake + 1 loop | 41 fps >quake + 2 loops | 2 fpsquake + 2 loops | 32 fps >quake + 3 loops | 1 fpsquake + 3 loops | 24 fps >quake + 4 loops | 0 fpsquake + 4 loops | 20 fps >quake + 5 loops | 0 fpsquake + 5 loops | 16 fps > > Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively > during any kind of load. The game is completely unusable with 1 CPU loop > running already! I run quake3 natively, ut2k4 natively, and world of warcraft under wine. > > Quake3-under-Wine behavior under CFS: framerate goes down gently with > load, gameplay remains smooth. Framerate is still pretty acceptable and > the game is playable even with a 500% CPU overload. The graph looks good > and the framerate reduction goes roughly along the expected 1/n > 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps > its fully 41 fps even with 1 competing loop running on the CPU due to > "sleeper fairness".] > > [ i've re-tested this using other SD and ck versions and other CFS > versions such as v2.6.23-rc1 and the results are the same. To get the > fps result i started a simple game scene: Single Player / > Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not > move the player at all, just looked at the framerate that is > displayed. (i also tried other scenes and other gameplay sections and > they all behave consistently with the above results.) The system was > otherwise completely idle. While i trust these numbers take them with > a grain of salt, i'm obviously not neutral in this thing :-) ] > > so Kasper, i'll definitely need your help in tracking down your 3D > smoothness problem under CFS. I have the feeling that it could be some > odd factor that only hits your system, and once we've tracked that down > there will be a simple solution that does not affect the totality of the > scheduler. So far only you have reported any 3D game smoothness problem > against recent CFS versions. (all 3D feedback has been positive, and > that includes a number of gamers as well. Most of the 3D smoothness > problems were fixed in CFS v13..v15 and it has not been reported to have > regressed since then.) I believe the responsibility for my situation is both IO and cpu load. i dont know why SD does this. my test is to make spamasassin process mails while i have these applications running(and wine is most sensitive, the difference is almost negligable in the native applications, but very much noticable with wine+wow) could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a "local" copy in my home. while i only see the spamasassin thread as hogging cpu, i suspect IO is also to blame. > > 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 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
On Sun, 2007-07-29 at 19:06 +0200, Ingo Molnar wrote: * Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. [...] here's an update: checking whether Wine could be a factor in your problem i just tested latest CFS against latest SD with a 3D game running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). Here are the results in a pretty graph: http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg or, in text: 2.6.22-ck1 2.6.22-cfs-v19 quake + 0 loops | 41 fpsquake + 0 loops | 41 fps quake + 1 loop | 3 fpsquake + 1 loop | 41 fps quake + 2 loops | 2 fpsquake + 2 loops | 32 fps quake + 3 loops | 1 fpsquake + 3 loops | 24 fps quake + 4 loops | 0 fpsquake + 4 loops | 20 fps quake + 5 loops | 0 fpsquake + 5 loops | 16 fps Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively during any kind of load. The game is completely unusable with 1 CPU loop running already! I run quake3 natively, ut2k4 natively, and world of warcraft under wine. Quake3-under-Wine behavior under CFS: framerate goes down gently with load, gameplay remains smooth. Framerate is still pretty acceptable and the game is playable even with a 500% CPU overload. The graph looks good and the framerate reduction goes roughly along the expected 1/n 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps its fully 41 fps even with 1 competing loop running on the CPU due to sleeper fairness.] [ i've re-tested this using other SD and ck versions and other CFS versions such as v2.6.23-rc1 and the results are the same. To get the fps result i started a simple game scene: Single Player / Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not move the player at all, just looked at the framerate that is displayed. (i also tried other scenes and other gameplay sections and they all behave consistently with the above results.) The system was otherwise completely idle. While i trust these numbers take them with a grain of salt, i'm obviously not neutral in this thing :-) ] so Kasper, i'll definitely need your help in tracking down your 3D smoothness problem under CFS. I have the feeling that it could be some odd factor that only hits your system, and once we've tracked that down there will be a simple solution that does not affect the totality of the scheduler. So far only you have reported any 3D game smoothness problem against recent CFS versions. (all 3D feedback has been positive, and that includes a number of gamers as well. Most of the 3D smoothness problems were fixed in CFS v13..v15 and it has not been reported to have regressed since then.) I believe the responsibility for my situation is both IO and cpu load. i dont know why SD does this. my test is to make spamasassin process mails while i have these applications running(and wine is most sensitive, the difference is almost negligable in the native applications, but very much noticable with wine+wow) could perhaps be filesystem related, i have my maildir(extremely large) on reiserfs, and /home on xfs. what my mail client will do is download mail, spamasassin it(loading database from home), then it will put to imap server placing it on reiserfs, and then a local copy in my home. while i only see the spamasassin thread as hogging cpu, i suspect IO is also to blame. 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/
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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kasper Sandberg <[EMAIL PROTECTED]> wrote: > Im still not so keen about this, Ingo never did get CFS to match SD in > smoothness for 3d applications, where my test subjects are quake(s), > world of warcraft via wine, unreal tournament 2004. [...] here's an update: checking whether Wine could be a factor in your problem i just tested latest CFS against latest SD with a 3D game running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). Here are the results in a pretty graph: http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg or, in text: 2.6.22-ck1 2.6.22-cfs-v19 quake + 0 loops | 41 fpsquake + 0 loops | 41 fps quake + 1 loop | 3 fpsquake + 1 loop | 41 fps quake + 2 loops | 2 fpsquake + 2 loops | 32 fps quake + 3 loops | 1 fpsquake + 3 loops | 24 fps quake + 4 loops | 0 fpsquake + 4 loops | 20 fps quake + 5 loops | 0 fpsquake + 5 loops | 16 fps Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively during any kind of load. The game is completely unusable with 1 CPU loop running already! Quake3-under-Wine behavior under CFS: framerate goes down gently with load, gameplay remains smooth. Framerate is still pretty acceptable and the game is playable even with a 500% CPU overload. The graph looks good and the framerate reduction goes roughly along the expected 1/n 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps its fully 41 fps even with 1 competing loop running on the CPU due to "sleeper fairness".] [ i've re-tested this using other SD and ck versions and other CFS versions such as v2.6.23-rc1 and the results are the same. To get the fps result i started a simple game scene: Single Player / Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not move the player at all, just looked at the framerate that is displayed. (i also tried other scenes and other gameplay sections and they all behave consistently with the above results.) The system was otherwise completely idle. While i trust these numbers take them with a grain of salt, i'm obviously not neutral in this thing :-) ] so Kasper, i'll definitely need your help in tracking down your 3D smoothness problem under CFS. I have the feeling that it could be some odd factor that only hits your system, and once we've tracked that down there will be a simple solution that does not affect the totality of the scheduler. So far only you have reported any 3D game smoothness problem against recent CFS versions. (all 3D feedback has been positive, and that includes a number of gamers as well. Most of the 3D smoothness problems were fixed in CFS v13..v15 and it has not been reported to have regressed since then.) 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: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* Kasper Sandberg [EMAIL PROTECTED] wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. [...] here's an update: checking whether Wine could be a factor in your problem i just tested latest CFS against latest SD with a 3D game running under Wine: v2.6.22-ck1 versus v2.6.22-cfsv19 (to get the most comparable kernel), using Quake 3 Arena Demo under Wine (0.9.41). Here are the results in a pretty graph: http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg or, in text: 2.6.22-ck1 2.6.22-cfs-v19 quake + 0 loops | 41 fpsquake + 0 loops | 41 fps quake + 1 loop | 3 fpsquake + 1 loop | 41 fps quake + 2 loops | 2 fpsquake + 2 loops | 32 fps quake + 3 loops | 1 fpsquake + 3 loops | 24 fps quake + 4 loops | 0 fpsquake + 4 loops | 20 fps quake + 5 loops | 0 fpsquake + 5 loops | 16 fps Quake3-under-Wine behavior under SD/-ck: framerate breaks down massively during any kind of load. The game is completely unusable with 1 CPU loop running already! Quake3-under-Wine behavior under CFS: framerate goes down gently with load, gameplay remains smooth. Framerate is still pretty acceptable and the game is playable even with a 500% CPU overload. The graph looks good and the framerate reduction goes roughly along the expected 1/n 'fairness curve' - so it all looks pretty healthy. [Note: quake3 keeps its fully 41 fps even with 1 competing loop running on the CPU due to sleeper fairness.] [ i've re-tested this using other SD and ck versions and other CFS versions such as v2.6.23-rc1 and the results are the same. To get the fps result i started a simple game scene: Single Player / Q3DM1 / I Can Win, turned on the fps display of Quake3, and did not move the player at all, just looked at the framerate that is displayed. (i also tried other scenes and other gameplay sections and they all behave consistently with the above results.) The system was otherwise completely idle. While i trust these numbers take them with a grain of salt, i'm obviously not neutral in this thing :-) ] so Kasper, i'll definitely need your help in tracking down your 3D smoothness problem under CFS. I have the feeling that it could be some odd factor that only hits your system, and once we've tracked that down there will be a simple solution that does not affect the totality of the scheduler. So far only you have reported any 3D game smoothness problem against recent CFS versions. (all 3D feedback has been positive, and that includes a number of gamers as well. Most of the 3D smoothness problems were fixed in CFS v13..v15 and it has not been reported to have regressed since then.) 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/
