Re: RSDL 0.31 causes slowdown
On Saturday 24 March 2007 04:57, Tim Chen wrote: > On Fri, 2007-03-23 at 13:40 +1100, Con Kolivas wrote: > > Volanomark is a purely yield() semantic dependant workload (as > > discussed many times previously). In the earlier form of RSDL I > > softened the effect of sched_yield but other changes since then have > > made that softness bordering on a noop. Obviously when sched_yield is > > relied upon that will not be enough. Extending the rr interval simply > > makes the yield slightly more effective and is not the proper > > workaround. Since expiration of arrays is a regular frequent > > occurrence in RSDL then changing yield semantics back to expiration > > should cause a massive improvement in these values, without making the > > yields as long as in mainline. It's impossible to know exactly what > > the final result will be since java uses this timing sensitive yield > > for locking but we can improve it drastically from this. I'll make a > > patch soon to change yield again. > > Con, > > The new RSDL 0.33 has fully recovered the loss in performance for > Volanomark. The throughput for Volanomark is at the same level as > mainline 2.6.21-rc4 kernel. > > Tim Thanks very much for testing. I'm quite happy with the yield semantics staying the way they are in rSDl 0.33+. -- -ck - 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: RSDL 0.31 causes slowdown
On Saturday 24 March 2007 04:57, Tim Chen wrote: On Fri, 2007-03-23 at 13:40 +1100, Con Kolivas wrote: Volanomark is a purely yield() semantic dependant workload (as discussed many times previously). In the earlier form of RSDL I softened the effect of sched_yield but other changes since then have made that softness bordering on a noop. Obviously when sched_yield is relied upon that will not be enough. Extending the rr interval simply makes the yield slightly more effective and is not the proper workaround. Since expiration of arrays is a regular frequent occurrence in RSDL then changing yield semantics back to expiration should cause a massive improvement in these values, without making the yields as long as in mainline. It's impossible to know exactly what the final result will be since java uses this timing sensitive yield for locking but we can improve it drastically from this. I'll make a patch soon to change yield again. Con, The new RSDL 0.33 has fully recovered the loss in performance for Volanomark. The throughput for Volanomark is at the same level as mainline 2.6.21-rc4 kernel. Tim Thanks very much for testing. I'm quite happy with the yield semantics staying the way they are in rSDl 0.33+. -- -ck - 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: RSDL 0.31 causes slowdown
On Fri, 2007-03-23 at 13:40 +1100, Con Kolivas wrote: > > Volanomark is a purely yield() semantic dependant workload (as > discussed many times previously). In the earlier form of RSDL I > softened the effect of sched_yield but other changes since then have > made that softness bordering on a noop. Obviously when sched_yield is > relied upon that will not be enough. Extending the rr interval simply > makes the yield slightly more effective and is not the proper > workaround. Since expiration of arrays is a regular frequent > occurrence in RSDL then changing yield semantics back to expiration > should cause a massive improvement in these values, without making the > yields as long as in mainline. It's impossible to know exactly what > the final result will be since java uses this timing sensitive yield > for locking but we can improve it drastically from this. I'll make a > patch soon to change yield again. > Con, The new RSDL 0.33 has fully recovered the loss in performance for Volanomark. The throughput for Volanomark is at the same level as mainline 2.6.21-rc4 kernel. Tim - 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: RSDL 0.31 causes slowdown
On Fri, 2007-03-23 at 13:40 +1100, Con Kolivas wrote: Volanomark is a purely yield() semantic dependant workload (as discussed many times previously). In the earlier form of RSDL I softened the effect of sched_yield but other changes since then have made that softness bordering on a noop. Obviously when sched_yield is relied upon that will not be enough. Extending the rr interval simply makes the yield slightly more effective and is not the proper workaround. Since expiration of arrays is a regular frequent occurrence in RSDL then changing yield semantics back to expiration should cause a massive improvement in these values, without making the yields as long as in mainline. It's impossible to know exactly what the final result will be since java uses this timing sensitive yield for locking but we can improve it drastically from this. I'll make a patch soon to change yield again. Con, The new RSDL 0.33 has fully recovered the loss in performance for Volanomark. The throughput for Volanomark is at the same level as mainline 2.6.21-rc4 kernel. Tim - 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: RSDL 0.31 causes slowdown
On 23/03/07, Tim Chen <[EMAIL PROTECTED]> wrote: Con, I've tried running Volanomark and found a 80% regression with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu system (4 cpus per socket, 8 cpus for system). The results are sensitive to rr_interval. Using Con's patch to increase rr_interval to a large value of 100, the regression reduced to 30% instead of 80%. I ran Volanomark in loopback mode with 10 chatrooms (20 clients per chatroom) configuration, with each client sending out 1 messages. http://www.volano.com/benchmarks.html There are significant differences in the vmstat runqueue profile between the 2.6.21-rc4 and the one with RSDL. There are a lot less runnable jobs (see col 2) with RSDL 0.31 (rr_interval=15) and higher idle time. Thanks Tim. Volanomark is a purely yield() semantic dependant workload (as discussed many times previously). In the earlier form of RSDL I softened the effect of sched_yield but other changes since then have made that softness bordering on a noop. Obviously when sched_yield is relied upon that will not be enough. Extending the rr interval simply makes the yield slightly more effective and is not the proper workaround. Since expiration of arrays is a regular frequent occurrence in RSDL then changing yield semantics back to expiration should cause a massive improvement in these values, without making the yields as long as in mainline. It's impossible to know exactly what the final result will be since java uses this timing sensitive yield for locking but we can improve it drastically from this. I'll make a patch soon to change yield again. -- -ck - 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: RSDL 0.31 causes slowdown
On Thu, Mar 22, 2007 at 01:21:46PM -0800, Tim Chen wrote: > I've tried running Volanomark and found a 80% regression > with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu > system (4 cpus per socket, 8 cpus for system). > The results are sensitive to rr_interval. Using Con's patch to increase > rr_interval to a large value of 100, > the regression reduced to 30% instead of 80%. > I ran Volanomark in loopback mode with 10 chatrooms > (20 clients per chatroom) configuration, with each client sending > out 1 messages. > http://www.volano.com/benchmarks.html > There are significant differences in the vmstat runqueue profile > between the 2.6.21-rc4 and the one with RSDL. > There are a lot less runnable jobs (see col 2) with RSDL 0.31 > (rr_interval=15) and higher idle time. This would be yield() semantics. A flag or alternate syscall for "hard" yield() semantics would resolve this (likely trapped into via LD_PRELOAD). It may also be useful to have a few variants of yield_to() (a.k.a. directed yields), such as ones donating timeslices by pid, by owner of sysv semaphore, by owner of futex, and to other ends of pipes and UNIX domain sockets if unique or otherwise able to be made sense of. It's unclear how easily the latter could be utilized by userspace, though, given the number of applications and libraries needing to be updated. -- wli - 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: RSDL 0.31 causes slowdown
On Thu, Mar 22, 2007 at 01:21:46PM -0800, Tim Chen wrote: I've tried running Volanomark and found a 80% regression with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu system (4 cpus per socket, 8 cpus for system). The results are sensitive to rr_interval. Using Con's patch to increase rr_interval to a large value of 100, the regression reduced to 30% instead of 80%. I ran Volanomark in loopback mode with 10 chatrooms (20 clients per chatroom) configuration, with each client sending out 1 messages. http://www.volano.com/benchmarks.html There are significant differences in the vmstat runqueue profile between the 2.6.21-rc4 and the one with RSDL. There are a lot less runnable jobs (see col 2) with RSDL 0.31 (rr_interval=15) and higher idle time. This would be yield() semantics. A flag or alternate syscall for hard yield() semantics would resolve this (likely trapped into via LD_PRELOAD). It may also be useful to have a few variants of yield_to() (a.k.a. directed yields), such as ones donating timeslices by pid, by owner of sysv semaphore, by owner of futex, and to other ends of pipes and UNIX domain sockets if unique or otherwise able to be made sense of. It's unclear how easily the latter could be utilized by userspace, though, given the number of applications and libraries needing to be updated. -- wli - 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: RSDL 0.31 causes slowdown
On 23/03/07, Tim Chen [EMAIL PROTECTED] wrote: Con, I've tried running Volanomark and found a 80% regression with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu system (4 cpus per socket, 8 cpus for system). The results are sensitive to rr_interval. Using Con's patch to increase rr_interval to a large value of 100, the regression reduced to 30% instead of 80%. I ran Volanomark in loopback mode with 10 chatrooms (20 clients per chatroom) configuration, with each client sending out 1 messages. http://www.volano.com/benchmarks.html There are significant differences in the vmstat runqueue profile between the 2.6.21-rc4 and the one with RSDL. There are a lot less runnable jobs (see col 2) with RSDL 0.31 (rr_interval=15) and higher idle time. Thanks Tim. Volanomark is a purely yield() semantic dependant workload (as discussed many times previously). In the earlier form of RSDL I softened the effect of sched_yield but other changes since then have made that softness bordering on a noop. Obviously when sched_yield is relied upon that will not be enough. Extending the rr interval simply makes the yield slightly more effective and is not the proper workaround. Since expiration of arrays is a regular frequent occurrence in RSDL then changing yield semantics back to expiration should cause a massive improvement in these values, without making the yields as long as in mainline. It's impossible to know exactly what the final result will be since java uses this timing sensitive yield for locking but we can improve it drastically from this. I'll make a patch soon to change yield again. -- -ck - 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/
