Re: TTY task group scheduling
On Thu Nov 18 10, Matthew D. Fuller wrote: > On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of > Alexander Best, and lo! it spake thus: > > > > judging from the videos the changes are having a huge impact imo. > > Well, my (admittedly limited, and certainly anecdotal) experience is > that Linux's interactive response when under heavy load was always > much worse than FreeBSD's. So maybe that's just them catching up to > where we already are ;) well...i tried playing back a 1080p vide files while doing `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. it might be possible that linux'es interactivity was worse than freebsd's, but still this patch should be evaluated for freebsd. in this particular case it seems linux now does better than freebsd. cheers. alex > > > -- > Matthew Fuller (MF4839) | fulle...@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ >On the Internet, nobody can hear you scream. -- a13x ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
On Thu Nov 18 10, Alexander Kabaev wrote: > On Thu, 18 Nov 2010 18:56:35 + > Alexander Best wrote: > > > On Thu Nov 18 10, Matthew D. Fuller wrote: > > > On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of > > > Alexander Best, and lo! it spake thus: > > > > > > > > judging from the videos the changes are having a huge impact imo. > > > > > > Well, my (admittedly limited, and certainly anecdotal) experience is > > > that Linux's interactive response when under heavy load was always > > > much worse than FreeBSD's. So maybe that's just them catching up to > > > where we already are ;) > > > > well...i tried playing back a 1080p vide files while doing > > `make -j64 buildkernel` and FreeBSD's interactivity seems far from > > perfect. > > One thing that just begs to be asked: since when decoding 1080p became > an interactive task? well i did exactly what they did in the video. watch a 1080p video and move the output window around while compiling the kernel. cheers. alex > > -- > Alexander Kabaev -- a13x ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
On Fri Nov 19 10, Daniel Nebdal wrote: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: > > On Thu, 18 Nov 2010 18:56:35 + > > Alexander Best wrote: > > > >> On Thu Nov 18 10, Matthew D. Fuller wrote: > >> > On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of > >> > Alexander Best, and lo! it spake thus: > >> > > > >> > > judging from the videos the changes are having a huge impact imo. > >> > > >> > Well, my (admittedly limited, and certainly anecdotal) experience is > >> > that Linux's interactive response when under heavy load was always > >> > much worse than FreeBSD's. So maybe that's just them catching up to > >> > where we already are ;) > >> > >> well...i tried playing back a 1080p vide files while doing > >> `make -j64 buildkernel` and FreeBSD's interactivity seems far from > >> perfect. > > > > One thing that just begs to be asked: since when decoding 1080p became > > an interactive task? > > > > Strictly speaking it isn't - but displaying it is a timing-sensitive > task that isn't CPU- or I/O-bound, and scheduling-wise that probably > makes it more like the "fast response when woken up" interactive tasks > than a CPU-bound non-interactive process. > Decoding it into another file on the disk is in the latter category, > of course - but I don't think that's what he meant. :) > > More on topic - while this was a tiny patch for Linux, it seems like > it would take more work for us, since I don't believe either of the > schedulers handles task groups in the required way. The linux patch > was just "create task groups automatically", since they already had > some suitable logic for scheduling based on task groups in their CFS > scheduler. We would have to (re-)add that first, which is non-trivial. personally i think freebsd would hugely benefit from a scheduler framework such as geom/gsched, where it's easy to switch between various algorithms. that way it be much easier to try out new concepts without having to write a completely new scheduler. cheers. alex > > > -- > Daniel Nebdal -- a13x ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: TTY task group scheduling
On Thu Nov 18 10, Julian Elischer wrote: > On 11/18/10 3:37 PM, Alexander Best wrote: > >On Fri Nov 19 10, Daniel Nebdal wrote: > >>On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev > >>wrote: > >>>On Thu, 18 Nov 2010 18:56:35 + > >>>Alexander Best wrote: > >>> > >>>>On Thu Nov 18 10, Matthew D. Fuller wrote: > >>>>>On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of > >>>>>Alexander Best, and lo! it spake thus: > >>>>>>judging from the videos the changes are having a huge impact imo. > >>>>>Well, my (admittedly limited, and certainly anecdotal) experience is > >>>>>that Linux's interactive response when under heavy load was always > >>>>>much worse than FreeBSD's. So maybe that's just them catching up to > >>>>>where we already are ;) > >>>>well...i tried playing back a 1080p vide files while doing > >>>>`make -j64 buildkernel` and FreeBSD's interactivity seems far from > >>>>perfect. > >>>One thing that just begs to be asked: since when decoding 1080p became > >>>an interactive task? > >>> > >>Strictly speaking it isn't - but displaying it is a timing-sensitive > >>task that isn't CPU- or I/O-bound, and scheduling-wise that probably > >>makes it more like the "fast response when woken up" interactive tasks > >>than a CPU-bound non-interactive process. > >>Decoding it into another file on the disk is in the latter category, > >>of course - but I don't think that's what he meant. :) > >> > >>More on topic - while this was a tiny patch for Linux, it seems like > >>it would take more work for us, since I don't believe either of the > >>schedulers handles task groups in the required way. The linux patch > >>was just "create task groups automatically", since they already had > >>some suitable logic for scheduling based on task groups in their CFS > >>scheduler. We would have to (re-)add that first, which is non-trivial. > >personally i think freebsd would hugely benefit from a scheduler framework > >such as geom/gsched, where it's easy to switch between various algorithms. > > > >that way it be much easier to try out new concepts without having to write > >a > >completely new scheduler. > > we are part of the way there.. > > at least we did abstract the scheduler to the point where > we have two completely different ones. > you are welcome to develop a 'framework as you describe and plug it into > the abstraction we already have. 17:49 @ arundel : also looking at the svn log shows that still a lot of \ commits happen to sched_4bsd. so it's defenately not being abbandoned. in \ fact there might be situations where it performs better than sched_ule. 17:50 @ arundel : i'm looking forward to a scheduler which looks sorta like \ geom and enables you to plugin addition plugins with different scheduling \ algorithms. :) 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* or \ thereabouts 17:51 @ Genesys : you could kldload new ones and switch to them on the fly 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it into src \ tree. by now it's probably outdated and needs to be reworked quite a bit. does anybody know something about this? i'm sorry. i'd really love to contribute some code, but my programing skills are pretty scrappy. ;) it would probably take me 20 years to figure out the current sched code. cheers. alex > > >cheers. > >alex > > > >> > >>-- > >>Daniel Nebdal -- a13x ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Sun Dec 18 11, Andrey Chernov wrote: > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: > > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: > > > On 13/12/2011 09:00, Andrey Chernov wrote: > > > > I observe ULE interactivity slowness even on single core machine > > (Pentium > > > > 4) in very visible places, like 'ps ax' output stucks in the middle by > > ~1 > > > > second. When I switch back to SHED_4BSD, all slowness is gone. > > > > > > I'm also seeing problems with ULE on a dual-socket quad-core Xeon machine > > > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 > > > buildworld" then logging into another console can take several seconds. > > > Sometimes even the "Password:" prompt can take a couple of seconds to > > appear > > > after typing my username. > > > > I'd resigned myself to expecting this sort of behaviour as 'normal' on > > my single core 1133MHz PIII-M. As a reproducable data point, running > > 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat > > the CPU while testing my manual fan control script, hogs it up pretty > > much while regularly running the script below in another konsole to > > check values - which often gets stuck half way, occasionally pausing > > _twice_ before finishing. Switching back to the first konsole (on > > another desktop) to kill the dd can also take a couple/few seconds. > > This issue not about slow machine under load, because the same > slow machine under exact the same load, but with SCHED_4BSD is very fast > to response interactively. > > I think we should not misinterpret interactivity with speed. I see no big > speed (i.e. compilation time) differences, switching schedulers, but see > big _interactivity_ difference. ULE in general tends to underestimate > interactive processes in favour of background ones. It perhaps helps to > compilation, but looks like slowpoke OS from the interactive user > experience. +1 i've also experienced issues with ULE and performed several tests to compare it to the historical 4BSD scheduler. the difference between the two does *not* seem to be speed (at least not a huge difference), but interactivity. one of the tests i performed was the following ttyv0: untar a *huge* (+10G) archive ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory contains a lot of files. i used "direcory = /var/db/portsnap", because that directory contains 23117 files on my machine. measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes > 15 seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. io operations usually get a high priority, because statistics have shown that - unlike computational tasks - io intensive tasks only run for a small fraction of time and then exit: read data -> change data -> writeback data. so SCHED_ULE might take these statistics too literaly and gives tasks like bsdtar(1) (in my case) too many ressources, so other tasks which require io are struggling to get some ressources assigned to them (ls(1) in my case). of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 testsuite. your whole system will grind to a halt. mouse input drops below 1 HZ. even after killing all the stress2 tests, it will take a few minutes after the system becomes snappy again. cheers. alex > > -- > http://ache.vniz.net/ ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Sun Dec 18 11, Alexander Best wrote: > On Sun Dec 18 11, Andrey Chernov wrote: > > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote: > > > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote: > > > > On 13/12/2011 09:00, Andrey Chernov wrote: > > > > > I observe ULE interactivity slowness even on single core machine > > > (Pentium > > > > > 4) in very visible places, like 'ps ax' output stucks in the middle > > > by ~1 > > > > > second. When I switch back to SHED_4BSD, all slowness is gone. > > > > > > > > I'm also seeing problems with ULE on a dual-socket quad-core Xeon > > > machine > > > > with 16 logical CPUs. If I run "tar xf somefile.tar" and "make -j16 > > > > buildworld" then logging into another console can take several seconds. > > > > Sometimes even the "Password:" prompt can take a couple of seconds to > > > appear > > > > after typing my username. > > > > > > I'd resigned myself to expecting this sort of behaviour as 'normal' on > > > my single core 1133MHz PIII-M. As a reproducable data point, running > > > 'dd if=/dev/random of=/dev/null' in one konsole, specifically to heat > > > the CPU while testing my manual fan control script, hogs it up pretty > > > much while regularly running the script below in another konsole to > > > check values - which often gets stuck half way, occasionally pausing > > > _twice_ before finishing. Switching back to the first konsole (on > > > another desktop) to kill the dd can also take a couple/few seconds. > > > > This issue not about slow machine under load, because the same > > slow machine under exact the same load, but with SCHED_4BSD is very fast > > to response interactively. > > > > I think we should not misinterpret interactivity with speed. I see no big > > speed (i.e. compilation time) differences, switching schedulers, but see > > big _interactivity_ difference. ULE in general tends to underestimate > > interactive processes in favour of background ones. It perhaps helps to > > compilation, but looks like slowpoke OS from the interactive user > > experience. > > +1 > > i've also experienced issues with ULE and performed several tests to compare > it to the historical 4BSD scheduler. the difference between the two does *not* > seem to be speed (at least not a huge difference), but interactivity. > > one of the tests i performed was the following > > ttyv0: untar a *huge* (+10G) archive > ttyv1: after ~ 30 seconds of untaring do 'ls -la $direcory', where directory >contains a lot of files. i used "direcory = /var/db/portsnap", because s/portsnap/portsnap\/files/ >that directory contains 23117 files on my machine. > > measuring 'ls -la $direcory' via time(1) revealed that SCHED_ULE takes > 15 > seconds, whereas SCHED_4BSD only takes ~ 3-5 seconds. i think the issue is io. > io operations usually get a high priority, because statistics have shown that > - unlike computational tasks - io intensive tasks only run for a small > fraction > of time and then exit: read data -> change data -> writeback data. > > so SCHED_ULE might take these statistics too literaly and gives tasks like > bsdtar(1) (in my case) too many ressources, so other tasks which require io > are > struggling to get some ressources assigned to them (ls(1) in my case). > > of course SCHED_4BSD isn't perfect, too. try using it and run the stress2 > testsuite. your whole system will grind to a halt. mouse input drops below > 1 HZ. even after killing all the stress2 tests, it will take a few minutes > after the system becomes snappy again. > > cheers. > alex > > > > > -- > > http://ache.vniz.net/ ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: SCHED_ULE should not be the default
On Mon Dec 19 11, Nathan Whitehorn wrote: > On 12/18/11 04:34, Adrian Chadd wrote: > >The trouble is that there's lots of anecdotal evidence, but noone's > >really gone digging deep into _their_ example of why it's broken. The > >developers who know this stuff don't see anything wrong. That hints to > >me it may be something a little more creepy - as an example, the > >interplay between netisr/swi/taskqueue/callbacks and such. It may be > >that something is being starved that isn't obviously obvious. It's > >just a stab in the dark, but it sounds somewhat plausible based on > >what I've seen ULE do in my network throughput hacking. > > > >I applaud reppie for trying to make it as easy as possible for people > >to use KTR to provide scheduler traces for him to go digging with, so > >please, if you have these issues and you can absolutely reproduce > >them, please follow his instructions and work with him to get him what > >he needs. > > The thing I've seen is that ULE is substantially more enthusiastic about > migrating processes between cores than 4BSD. Often, this is a good > thing, but can increase the rate of cache misses, hurting performance > for cache-bound processes (I see this particularly in HPC-type > scientific workloads). It might be interesting to add some kind of > tunable here. does r228718 have any impact regarding this behaviour? cheers. alex > > Another more interesting and slightly longer-term possibility if someone > wants a project would be to integrate scheduling decisions with hwpmc > counters, to accumulate statistics on cache hits at each context switch > and preferentially keep processes with a high hits/misses ratio on the > same thread/cache domain relative to processes with a low one. > -Nathan > > P.S. The other thing that could be very interesting from a research and > scheduling standpoint would be to integrate heterogeneous SMP support > into the operating system, with a FreeBSD-4 "Application Processor" > syscall model. We seem to be going down the road where GPGPU computing > has MMUs, timer interrupts, IPIs, etc. (the next AMD Fusions, IBM Cell). > This is something that no operating system currently supports well, and > would be a place for BSD to shine. If anyone has a free graduate student... ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Fri Dec 23 11, Daniel Kalchev wrote: > > > On 23.12.11 08:47, Martin Sugioarto wrote: > >A further thing is that I cannot understand the people here sometimes. > >I would like that the -RELEASE versions of FreeBSD perform well > >without any further optimizations. > > The -RELEASE things is just a freeze (or, let's say tested freeze) of > the corresponding branch at some time. It is the code available and > tested at that time. > > Thus, it is safe to say that FreeBSD 8.0-RELEASE is much worse than > FreeBSD RELENG_8 (still 8.2 at the moment), because years have passed > between both code bases, lots of bugs have been discovered and fixed and > new technologies have been integrated. Especially in this line, the > compiler has changed from 4.2.1 to 4.2.2. > > >When the distribution does not compile with the latest compiler it's > >simply a bug. > > FreeBSD is not a distribution. It also compiles with the latest compiler > - LLVM. :) > > I find it amusing, that people want everything compiled with GCC 4.7, > which is still very much developing, therefore highly unstable and > (probably) full of bugs. > > >Why should one try to penalize the other distribution and downgrade > >their binaries? > > Many suggested that the Linux binaries be run via the FreeBSD Linux > emulation. Unchanged. > There is one problem here though, the emulation is still 32 bit. plus the current emulation layer is far from complete. a lot of stuff hasn't been implemented yet (meaning it's missing or implemented as dummy code). try running recent firefox linux binaries on freebsd. they will all crash almost instantly. cheers. alex > > >When FreeBSD has a bad default setup, there must be a reason for that. > >Tell me this reason and show me that it's justified in form of some > >other benchmark. > > FreeBSD has safe default. It is supposed to work out of the box on > whatever hardware you put it. As much as it has drives for that > hardware, of course. > Once you have working installation, you may tweak it all the way you wish. > > If your installation is pre-optimized, chances are it will crash all the > time on you and there will be no easy way for you to fix, short of > installing another "distribution". > > Daniel ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
