Re: TTY task group scheduling
On Fri, 19 Nov 2010, Kostik Belousov wrote: On Fri, Nov 19, 2010 at 11:50:49AM +0200, Andriy Gapon wrote: on 19/11/2010 11:46 Bruce Cran said the following: [removed current@ and stable@ from the Cc list] On Fri, 19 Nov 2010 15:41:29 +1100 Andrew Reilly wrote: On Linux. Have you ever seen those sorts of UI problems on FreeBSD? Not since FreeBSD-1 or earlier, but I don't run much bloatware. I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. I've definitely seen problems when running builds in an xterm. I've often resorted to canceling it and running it on a syscons console instead to improve performance. So, what was it a problem with scheduler or with, e.g., "something X" being too slow rendering glyphs? Who can tell... Probably will pay a lot in negative karma by posting anything in the thread. But I can confirm your words, that tty->xterm->X server chain of output indeed significantly slows down the build processes. I just tried a kernel build with -j256 on a 1-core system to be unreasnable, and didn't see any sluggishness (and I notice programs taking > 10 msec to start up), but this was under my version of 5.2 with my version of SCHED_4BSD. I usually never start build in the barebone xterm, always running screen under xterm. make -j 10 on 4 core/HTT cpu slows up to a half, from my unscientific impression, when run in the active screen window. Switching to other window in screen significantly speeds it up (note the prudent omission of any measured numbers). For me, make -s -j 256 on 1 core ran at the same speed in an xterm with another xterm watching it using top. Without -s it took 5% longer. The X output is apparently quite slow. But I rarely run X. Syscons output is much more efficient. make(1) has interesting problems determining when jobs finish. It used to wait 10 msec (?) and that gave a lot of dead time whan 10 msec became a long time for a process runtime. Maybe X is interfering with its current mechanism. During the make -j256, the load average went up to about 100 and most of the cc1's reached a low (numerically high) priority very quickly, especially on the second run when the load average was high to start (my version of the SCHED_4BSD may affect how fast or slow the priority ramps up). An interactive process competing with these cc1's has a very easy time getting scheduled to run provided it is not a bloated one that runs enough to gain a high priority itself. If it runs as much as the cc1's then it will become just one of 257 processes wanting to run and it takes a very unfair scheduler to do much better than run 1 every (default 100 msec) and thus take a default of 25.7 seconds to get back to the interactive one. At least old versions of SCHED_4BSD had significant bugs that often resulted in very unfair scheduling that happened to favour interactive processes but sometimes went the other way. The most interesting one is still there :-( : sched_exit_thread() adds the child td_estcpu to the parent td_estcpu. Combined with the inheritance of td_estcpu on fork(), this results in td_estcpu being exponential in the number of reaped children, except td_estcpu is clamped to a maximum, so td_estcpu quickly reaches the maximum td_estcpu (and td_priority quickly reaches the minimum (numerical maximum) user priority) after a few fork/exit/waits. The process doing the fork/waits is often a shell, and its interactivity becomes bad when its priority becomes low. Between about 1995 and 2000, this bug was much worse. Then there was no clamp, so td_estcpu was fully exponential in the number of children, except after about 32 doublings it overflowed to a negative value. But before it became negative, it became large, so its process gained the maximum priority and therefore found it hard to run enough to create more children. This still happens with the clamp, but "large" is now quite small and decays after a few seconds or minutes. Without the clamp, the decay took minutes or hours if not days. The doubling is fixed in my version by setting the parent td_estcpu to the maximum of the parent and child estcpu's on exit. This risks not inheriting enough (I now see a simple better method: add only the part of the child's td_estcpu that was actually due to child activity and is not just virtual cpu created on fork). The doubling was originally implemented to improve interactivity, and it "worked" bogusly by inibiting forks. E.g., for -j 256, it would probably stop make forking long before it created 256 jobs. Now with the clamp, make will just take longer to create the 256 jobs once it increased its td_estcpu to more than that of the first few jobs its started by reaping a few. Well, I tried this under -current, but only have SCHED_ULE handy to test (on a FreeBSD cluster machine). -j256 didn't seem to be enough t
Re: TTY task group scheduling
On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter wrote: > My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP > system), > I tested 8-STABLE, but that is not too responsive, the solution is: > 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 > After this setting, the system is likely responsive as 7-STABLE. > > On 11/19/10, Garrett Cooper wrote: >> On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter >> wrote: >>> http://lkml.org/lkml/2010/11/16/392 >>> >>> On 11/18/10, O. Hartmann wrote: On 11/18/10 02:30, grarpamp wrote: > Just documenting regarding interactive performance things. > This one's from Linux. > > http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 Well, it would be nice to have those improvements in FreeBSD, but I doubt this will make it in due time to FreeBSD's kernel. >> >> And my one line fix: >> >> renice 10 `pidof firefox-bin` >> >> Instantly my system is snappier (and in fact my system got really >> laggy after applying the preempt sysctl that everyone recommended >> before)... Performance issue with firefox maybe :P? I don't see the >> point of adding an additional layer to complicate the system (and >> essentially slow it down) if all you're trying to do is better >> describe the nice'ing problem, unless this logic is what you want to >> do strictly for desktop users in PCBSD, etc who may not have the >> technical wherewithal to accomplish this task. >> >> Besides, the Linux kernel has different compile time profiles for >> different workloads, so maybe it just works better for them because >> they already have a means for describing that functionality, whereas >> FreeBSD is more generic. >> >> It would be nice to describe this in a document though so people could >> also decide how to tune the system for themselves and not deal with a >> patch like what's noted above by the penguin crowd because it will >> invariably fail under some workloads or conditions (I have yet to see >> a one-size-fits-all solution in this area). >> >> >> SCHED_ULE improvements though should be looked into if possible, >> because there are some potential items that could be done to cluster >> processes together better, maybe. >> Ugh. Looks like this was the only machine that I setup recently where I didn't set kern.hz... Ok, will retry after building and installing a whole new world *queue lame Disney music here* and kernel. Thanks for the obvious reminder... -Garrett ___ 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
My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system), I tested 8-STABLE, but that is not too responsive, the solution is: 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 After this setting, the system is likely responsive as 7-STABLE. On 11/19/10, Garrett Cooper wrote: > On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter > wrote: >> http://lkml.org/lkml/2010/11/16/392 >> >> On 11/18/10, O. Hartmann wrote: >>> On 11/18/10 02:30, grarpamp wrote: Just documenting regarding interactive performance things. This one's from Linux. http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>> >>> Well, >>> it would be nice to have those improvements in FreeBSD, but I doubt this >>> will make it in due time to FreeBSD's kernel. > > And my one line fix: > > renice 10 `pidof firefox-bin` > > Instantly my system is snappier (and in fact my system got really > laggy after applying the preempt sysctl that everyone recommended > before)... Performance issue with firefox maybe :P? I don't see the > point of adding an additional layer to complicate the system (and > essentially slow it down) if all you're trying to do is better > describe the nice'ing problem, unless this logic is what you want to > do strictly for desktop users in PCBSD, etc who may not have the > technical wherewithal to accomplish this task. > > Besides, the Linux kernel has different compile time profiles for > different workloads, so maybe it just works better for them because > they already have a means for describing that functionality, whereas > FreeBSD is more generic. > > It would be nice to describe this in a document though so people could > also decide how to tune the system for themselves and not deal with a > patch like what's noted above by the penguin crowd because it will > invariably fail under some workloads or conditions (I have yet to see > a one-size-fits-all solution in this area). > > > SCHED_ULE improvements though should be looked into if possible, > because there are some potential items that could be done to cluster > processes together better, maybe. > > > Thanks, > -Garrett > ___ 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
In the last episode (Nov 19), Alexander Leidinger said: > Quoting Alexander Best (from Fri, 19 Nov 2010 00:17:10 > +): > > 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 aware of the I/O scheduling code (which is now available at least > in -current), but I do not remember CPU scheduling code from Luigi. > Are you sure Genesys didn't mix up something by accident? I am rarely mixed up :) A quick search didn't bring up a direct reference, but here's a mention of it from Luigi: http://lists.freebsd.org/pipermail/freebsd-hackers/2004-November/008891.html -- Dan Nelson dnel...@allantgroup.com ___ 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, 2010 at 1:10 PM, Oliver Pinter wrote: > http://lkml.org/lkml/2010/11/16/392 > > On 11/18/10, O. Hartmann wrote: >> On 11/18/10 02:30, grarpamp wrote: >>> Just documenting regarding interactive performance things. >>> This one's from Linux. >>> >>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >> >> Well, >> it would be nice to have those improvements in FreeBSD, but I doubt this >> will make it in due time to FreeBSD's kernel. And my one line fix: renice 10 `pidof firefox-bin` Instantly my system is snappier (and in fact my system got really laggy after applying the preempt sysctl that everyone recommended before)... Performance issue with firefox maybe :P? I don't see the point of adding an additional layer to complicate the system (and essentially slow it down) if all you're trying to do is better describe the nice'ing problem, unless this logic is what you want to do strictly for desktop users in PCBSD, etc who may not have the technical wherewithal to accomplish this task. Besides, the Linux kernel has different compile time profiles for different workloads, so maybe it just works better for them because they already have a means for describing that functionality, whereas FreeBSD is more generic. It would be nice to describe this in a document though so people could also decide how to tune the system for themselves and not deal with a patch like what's noted above by the penguin crowd because it will invariably fail under some workloads or conditions (I have yet to see a one-size-fits-all solution in this area). SCHED_ULE improvements though should be looked into if possible, because there are some potential items that could be done to cluster processes together better, maybe. Thanks, -Garrett ___ 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
http://lkml.org/lkml/2010/11/16/392 On 11/18/10, O. Hartmann wrote: > On 11/18/10 02:30, grarpamp wrote: >> Just documenting regarding interactive performance things. >> This one's from Linux. >> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > Well, > it would be nice to have those improvements in FreeBSD, but I doubt this > will make it in due time to FreeBSD's kernel. > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ 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
Alexander writes: One thing that just begs to be asked: since when decoding 1080p became an interactive task? Normally, decoding video would not be considered an interactive task, unless you are doing things like stepping through frame-by-frame. Playing video, and/or audio is a true real time task. The computer must perform the work at a specific rate, not faster, not slower. Recording video and/or audio is also a true real time task, If the machine/OS drops the ball you have a spoiled recording, and most of the time you can't try again. Bruce writes: you can have a load of 100 or more before the system becomes unusable whereas people are amazed to see loads of more than 15 on Linux. The load average leaves much to be desired as a metric. I have generated an obscenely high lead average while retaining great responsiveness, and done a simple "cp /disk1/file1 /disk2/" resulting in the machine taking *minutes* to respond to the simplest command. Andriy writes: Well, I am not sure if I can agree about CPU-bound-ness. Depends on the exact video file, of course, but certain high-quality 1080p are very CPU intensive unless decoding is offloaded from the CPU. Depends on decoder code too. I had some videos that were CPU-bound on my Athlon II X2 250 with then-version of mplayer from ports. The bitrate is more useful than saying "1080p". The speed of the CPU is important, the codec, the efficiency of the decoder, whether parts can be offloaded to a GPU or hardware decoder, if the output is being scaled, etc. If playing a video maxes out the CPU, then the video isn't going to be displayed correctly. ___ 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, 18 Nov 2010 21:30:16 +0100 "O. Hartmann" wrote: > On 11/18/10 19:55, Lucius Windschuh wrote: > > 2010/11/18 Andriy Gapon: > >> [Grouping of processes into TTY groups] > >> > >> Well, I think that those improvements apply only to a very specific usage > >> pattern > >> and are greatly over-hyped. > > > > But there are serious issue if you use FreeBSD as a desktop OS with > > SMP and SCHED_ULE, or? > > Because currently, my machine is barely usable if a compile job with > > parallelism is running. Movies stutter, Firefox hangs. And even nice > > -n 20 doesn't do the job in every case, as +20 seems not to be the > > idle priority anymore?!? > > And using "idprio 1 $cmd" as a workaround is, well, a kludge. > > I am not sure if TTY grouping is the right solution, if you look at > > potentially CPU-intensive GUI applications that all run on the same > > TTY (or no TTY at all? Same problem). > > Maybe, we could simply enhance the algorithm that decides if a task is > > interactive? That would also improve the described situation. > > > > Regards, > > > > Lucius > > Stuttering Response, being stuck for over 20 seconds also happens when I > start updating the OS' sources via svn. This happens on all boxes, some > of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O, > doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those > phenomena are most seen when you interact with the machine via X11 > clients. I think it's hard to realize if a server only does console I/O, > but console also seems to be stuck sometimes. It would be worth checking > this with some 'benchmark'. X11 in its kind of oldish incarnation on > FreeBSD seems to contribute most to those slowdowns, what so ever. I guess schedulers can hardly distinguish heavy disk I/Os from nanosleep()s and user-interactions; schedulers think both as voluntary sleep. To make the matters worse, the current implementation of SCHED_ULE reassigns ts_slice on sched_wakeup() no matter how short the sleep was. I have a dumb local hack to grant ts_slice proportional to the duration the waking thread slept rather than unconditionally reset to sched_slice. --- sys/kern/sched_ule.c.orig +++ sys/kern/sched_ule.c @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) u_int hzticks; hzticks = (ticks - slptick) << SCHED_TICK_SHIFT; + if (hzticks > SCHED_SLP_RUN_MAX) + hzticks = SCHED_SLP_RUN_MAX; ts->ts_slptime += hzticks; + /* Grant additional slices after we sleep. */ + ts->ts_slice += hzticks / tickincr; + if (ts->ts_slice > sched_slice) + ts->ts_slice = sched_slice; sched_interact_update(td); sched_pctcpu_update(ts); } - /* Reset the slice value after we sleep. */ - ts->ts_slice = sched_slice; sched_add(td, SRQ_BORING); } -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - ___ 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, 2010 at 02:18:52PM +, Vincent Hoffman wrote: > On 19/11/2010 12:42, Eric Masson wrote: > > Bruce Cran writes: > > > > Hello, > > > >> Google suggests that the work was a GSoC project in 2005 on a pluggable > >> disk scheduler. > > It seems that something similar has found its way in DFlyBSD, dsched. > And indeed to FreeBSD, man gsched. Added sometime round April > http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log It's been pointed out on the list a couple times, and I've sent mail to the authors about this, that gsched breaks (very, very badly) things like sysinstall, and does other strange things like leaves trailing periods at the end of its ".sched." labels. This appears to be by design, but I'm still left thinking "?!" It's hard to discern technical innards/workings of GEOM since the documentation is so poor (and reading the code doesn't help, especially with regards to libgeom). IMHO, the gsched "stuff", as a "layer", should probably be moved into the I/O framework by default, with the functionality *disabled* by default and tunables to adjust it. That's just how I feel about it. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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, 2010 at 11:50:49AM +0200, Andriy Gapon wrote: > on 19/11/2010 11:46 Bruce Cran said the following: > > [removed current@ and stable@ from the Cc list] > > > > On Fri, 19 Nov 2010 15:41:29 +1100 > > Andrew Reilly wrote: > > > >> On Linux. Have you ever seen those sorts of UI problems on FreeBSD? > >> I don't watch much video on my systems, but I haven't seen that. > >> FreeBSD has always been good at keeping user-interactive processes > >> responsive while compiles or what-not are going on in the background. > > > > I've definitely seen problems when running builds in an xterm. I've > > often resorted to canceling it and running it on a syscons console > > instead to improve performance. > > > > So, what was it a problem with scheduler or with, e.g., "something X" > being too slow rendering glyphs? Who can tell... Probably will pay a lot in negative karma by posting anything in the thread. But I can confirm your words, that tty->xterm->X server chain of output indeed significantly slows down the build processes. I usually never start build in the barebone xterm, always running screen under xterm. make -j 10 on 4 core/HTT cpu slows up to a half, from my unscientific impression, when run in the active screen window. Switching to other window in screen significantly speeds it up (note the prudent omission of any measured numbers). pgpo6EkgdvCp0.pgp Description: PGP signature
Re: TTY task group scheduling
On 19/11/2010 12:42, Eric Masson wrote: > Bruce Cran writes: > > Hello, > >> Google suggests that the work was a GSoC project in 2005 on a pluggable >> disk scheduler. > It seems that something similar has found its way in DFlyBSD, dsched. And indeed to FreeBSD, man gsched. Added sometime round April http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log Vince > Éric Masson > ___ 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 18/11/2010 22:20 Julian Elischer said the following: > tty grouping is a variant of what we used to have at one stage which is > a "kernel schedulable entity group".. KSEG Or rather, I think, a concrete application of a variant of that. > the idea is that all items in a group share some characteristic and some > amount > of resources. > > We stripped the KSEG out of the picture because it really complicated the > picture. Yes, unfortunately. One can think about a number of applications for hierarchical schedulable resources. Even one-level group scheduling could be a very useful subcase. BTW, http://www.mjmwired.net/kernel/Documentation/cgroups.txt -- Andriy Gapon ___ 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
Bruce Cran writes: Hello, > Google suggests that the work was a GSoC project in 2005 on a pluggable > disk scheduler. It seems that something similar has found its way in DFlyBSD, dsched. Éric Masson -- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://www.le-gnu.net : Les oiseaux sont des cons. ___ 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
Quoting Alexander Best (from Fri, 19 Nov 2010 00:17:10 +): 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 aware of the I/O scheduling code (which is now available at least in -current), but I do not remember CPU scheduling code from Luigi. Are you sure Genesys didn't mix up something by accident? Bye, Alexander. -- Ferengi Rule of Acquisition #123: Even a blind man can recognize the glow of latinum. -- ST: Legends of the Ferengi http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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 19/11/2010 11:46 Bruce Cran said the following: > [removed current@ and stable@ from the Cc list] > > On Fri, 19 Nov 2010 15:41:29 +1100 > Andrew Reilly wrote: > >> On Linux. Have you ever seen those sorts of UI problems on FreeBSD? >> I don't watch much video on my systems, but I haven't seen that. >> FreeBSD has always been good at keeping user-interactive processes >> responsive while compiles or what-not are going on in the background. > > I've definitely seen problems when running builds in an xterm. I've > often resorted to canceling it and running it on a syscons console > instead to improve performance. > So, what was it a problem with scheduler or with, e.g., "something X" being too slow rendering glyphs? Who can tell... -- Andriy Gapon ___ 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, 19 Nov 2010 00:17:10 + Alexander Best wrote: > 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? Google suggests that the work was a GSoC project in 2005 on a pluggable disk scheduler. -- Bruce Cran ___ 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 19/11/2010 00:55 Daniel Nebdal said the following: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: >> On Thu, 18 Nov 2010 18:56:35 + >> Alexander Best wrote: >>> 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 Well, I am not sure if I can agree about CPU-bound-ness. Depends on the exact video file, of course, but certain high-quality 1080p are very CPU intensive unless decoding is offloaded from the CPU. Depends on decoder code too. I had some videos that were CPU-bound on my Athlon II X2 250 with then-version of mplayer from ports. YMMV. -- Andriy Gapon ___ 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 18/11/2010 20:56 Alexander Best said the following: > 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. You do realize that there are many more variables for such a test than just "1080p video" and "make -j64 buildkernel"? Let's not forget about hardware, video drivers, player capabilities, exact kind of the video (you know, 1080p alone doesn't tell much). Besides, someone might be interested in running -j64 on his 1,2,4-core desktop system, but it's definitely not me. I prefer to be reasonable. I am not saying that our scheduler (ULE) is perfect. I don't even say that it's better (in whatever comparison system) than Linux scheduler X. I say that I wouldn't spend my time improving system behavior in a scenario like this. I compile stuff very frequently (kernels, ports, world) while browsing web, reading email, doing various "desktop stuff", sometimes watching videos from the web (like e.g. trailers). On this machine/hardware I have never personally felt a need for improvements in the scheduler. And I run KDE4 with all bells and whistles enabled. YMMV. P.S. I don't discourage anyone from improving our scheduler, I even do encourage that. -- Andriy Gapon ___ 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, 2010 at 06:23:24PM +, Alexander Best wrote: > you think so? judging from the videos the changes are having a huge impact > imo. On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. Cheers, -- Andrew ___ 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 11/19/10 10:46, Bruce Cran wrote: [removed current@ and stable@ from the Cc list] On Fri, 19 Nov 2010 15:41:29 +1100 Andrew Reilly wrote: On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. I've definitely seen problems when running builds in an xterm. I've often resorted to canceling it and running it on a syscons console instead to improve performance. A simple test: use X11, simply use windowmaker as the GUI (this is my configuration on most FreeBSD boxes around here in use for scientidic duties). The simply update your siurce tree via 'svn update' and warch responsivenes of your desktop. Or try start building world AND do something other, like building a big port like something from Qt4. I realize hangs and stuttering on the following FreeBSD OS' and hardware: FreeBSD 8.1-STABLE/amd64: box with 8 GB RAM, Intel Q6600 4-core CPU, UFS2 filesystem containing root. Another box 4 GB RAM, Intel E8400 2-core CPU, also UFS2 as the base filesystem. Both boxes use X11. The next box is our number crunching server, DELL Poweredge1950III, 16 GB RAM, two CPU XEON hw.model: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz. No GUI. Base filesystem on which is build done: UFS2. These boxes have a significant 'stutter' and hang, when starting updating source tree or start building the base system, visible on each xterm or ssh session connected to the box (this is for the server which has no GUI). FreeBSD 9.0-CURRENT/amd64: Notebook, 4GB RAM, CPU: Intel Core i-5 with 2,4 GHz. Base filesystem UFS2, graphical device nVidia XM3100 with nVidia most reent 64bit BLOB driver for this kind of hardware. On the notebook the drop in performance and responsivenes is amazing, the box is 'dead' for a minute when doing 'svn update' for the source tree. I do not know whether those hangs are due to the topic of this thread, I doubt it is more due to a weakness of the I/O subsystem dealing with harddrives (I see hangs while on heavy load also on our ZFS homes). Since our institute uses several Linux flavors around here of several revisions I have some 'naive' comparisons. Even on heavy I/O load Linux does respond nicely. Our 8 core FreeBSD box runs some modelling software for astrodynamics, the software is 'serial', not yet parallelized, but even utilizing 6 out of 8 cores and push them under heavy load does not bother the system and the server responding is good. But any kind of heavy HD I/O, even if this job utilizes only one CPU (as far as I can guess), it gets worse. ___ 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, 19 Nov 2010 11:50:49 +0200 Andriy Gapon wrote: > So, what was it a problem with scheduler or with, e.g., "something X" > being too slow rendering glyphs? Who can tell... There are too many components involved when running the Linux benchmark of running a build to know the scheduler is at fault. However the slowdown did still exist when I minimized the window. I've at least found that the FreeBSD schedulers can scale much better than Linux: you can have a load of 100 or more before the system becomes unusable whereas people are amazed to see loads of more than 15 on Linux. -- Bruce Cran ___ 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
[removed current@ and stable@ from the Cc list] On Fri, 19 Nov 2010 15:41:29 +1100 Andrew Reilly wrote: > On Linux. Have you ever seen those sorts of UI problems on FreeBSD? > I don't watch much video on my systems, but I haven't seen that. > FreeBSD has always been good at keeping user-interactive processes > responsive while compiles or what-not are going on in the background. I've definitely seen problems when running builds in an xterm. I've often resorted to canceling it and running it on a syscons console instead to improve performance. -- Bruce Cran ___ 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 Nov 18, 2010, at 18:43, Julian Elischer wrote: 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. It may be something to suggest for the next round of Google's Summer of Code. Or perhaps part of a school project in operating systems work (master's level? eager-beaver bachelor's thesis?). Having a bit more flexibility in being able to make different components "pluggable" would help encourage the use of BSD in more research projects. And more people learning and hacking on BSD can't be a bad thing. :) ___ 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
Lucius Windschuh wrote: 2010/11/18 Bruce Cran : Have you tried increasing kern.sched.preempt_thresh? According to http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/82affa9f195b747d?lnk=raot&fwc=1&pli=1 a good value for desktop use would be 224. Hmm, I though I tried this -- but this helps indeed. :-) The browser, movie player etc. behave much better when a "make -j4 buildworld" is running on my 2-core machine in the background. Thank you. 2010/11/18 Bruce Cran : If you're using UFS, I've found it to be quite a bottleneck when doing parallel IO: I even ran a "svn up" in one terminal and tried to login on another a couple of days ago only to find the motd took over 5 seconds to appear! That may be excessive since I was running a kernel with WITNESS and INVARIANTS, but I've found ZFS to be far better if you want good interactivity when reading/writing to disks. This is indeed another issue, which I also encountered, but explicitly left out since I don't blame the task scheduler for that. ;) Unfortunately, I don't know how much SCHED_ULE's inability to cope with more runnable threads than cores, as Steve mentioned, accounts to the problem I observe. Time to switch back to SCHED_4BSD? *sigh* Lucius Sometimes, I am thinking that our thread scheduler should be split into two layers, looks like Solaris did, the sched_ule really should only be responsible for CPU dispatching, it only cares where a thread should be dispatched based on CPU-affinity, each CPU's load, ... Another layer is how to calculate thread's priority for time-sharing thread, you can specify which priority algorithm to used, static or dynamic priority scheduling, ULE's algorithm or 4BSD. with cpuset, one even can bind all real-time processes to a specific cpu group, they needn't to be a superuser to run real-time thread. Regards, David Xu ___ 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, 2010 at 11:23 PM, Lucius Windschuh wrote: > 2010/11/18 Bruce Cran : >>Have you tried increasing kern.sched.preempt_thresh? According to >>http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/82affa9f195b747d?lnk=raot&fwc=1&pli=1 >>a good value for desktop use would be 224. > > Hmm, I though I tried this -- but this helps indeed. :-) > The browser, movie player etc. behave much better when a "make -j4 > buildworld" is running on my 2-core machine in the background. Thank > you. > > 2010/11/18 Bruce Cran : >> If you're using UFS, I've found it to be quite a bottleneck when >> doing parallel IO: I even ran a "svn up" in one terminal and tried to >> login on another a couple of days ago only to find the motd took over 5 >> seconds to appear! That may be excessive since I was running a kernel >> with WITNESS and INVARIANTS, but I've found ZFS to be far better if you >> want good interactivity when reading/writing to disks. > > This is indeed another issue, which I also encountered, but explicitly > left out since I don't blame the task scheduler for that. ;) > > Unfortunately, I don't know how much SCHED_ULE's inability to cope > with more runnable threads than cores, as Steve mentioned, accounts to > the problem I observe. Time to switch back to SCHED_4BSD? *sigh* OT: Compare building kernel on tmpfs vs ufs on mdX vs ufs on usb stick and guess what is faster and does not cause non interactive mouse movement. ___ 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: TTY task group scheduling
On Thu, Nov 18, 2010 at 3:12 PM, Steve Kargl wrote: > On Thu, Nov 18, 2010 at 10:59:43PM +, Alexander Best wrote: >> >> well i did exactly what they did in the video. watch a 1080p video and move >> the output window around while compiling the kernel. >> > > It is trivial to bring ULE to its knees. If you > have N cores then all you need is N+1 cpu intensive > task. The issue has been known for a few years. I/O intensive tasks don't help either though. Things tend to get choppy whenever I'm doing something like update from svn and doing something a bit more interactive like use firefox (and scroll... for instance gmail seems to be a pig in this area -- heh), vlc is a little less painful, etc. I wonder if the issue isn't necessarily tasks but more or less locking. firefox uses a lot of threads and file based mutexes according to what I've seen with top and ps (please correct me if I'm wrong). firefox also has a tendency with the nvidia-driver (I know... blobs are bad) to produce funky artifacts on the screen (again, when scrolling on gmail, dealing with flash, etc) or certain bits don't redraw properly (text when scrolling ends up ghosting on multiple lines until I force a redraw with the cursor or by scrolling back over that section of text). I'm sure there are a lot of performance issues within FreeBSD and opensource desktop software that needs to be properly worked out on a case by case basis, so I think that writing everything off as awesome and working better with one magic patch is unlikely. Besides, Linux has a more complicated scheduler than FreeBSD does. Thanks, -Garrett ___ 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 + 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 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. cheers. alex -- Daniel Nebdal ___ 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, 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. -- Daniel Nebdal ___ 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
2010/11/18 Bruce Cran : >Have you tried increasing kern.sched.preempt_thresh? According to >http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/82affa9f195b747d?lnk=raot&fwc=1&pli=1 >a good value for desktop use would be 224. Hmm, I though I tried this -- but this helps indeed. :-) The browser, movie player etc. behave much better when a "make -j4 buildworld" is running on my 2-core machine in the background. Thank you. 2010/11/18 Bruce Cran : > If you're using UFS, I've found it to be quite a bottleneck when > doing parallel IO: I even ran a "svn up" in one terminal and tried to > login on another a couple of days ago only to find the motd took over 5 > seconds to appear! That may be excessive since I was running a kernel > with WITNESS and INVARIANTS, but I've found ZFS to be far better if you > want good interactivity when reading/writing to disks. This is indeed another issue, which I also encountered, but explicitly left out since I don't blame the task scheduler for that. ;) Unfortunately, I don't know how much SCHED_ULE's inability to cope with more runnable threads than cores, as Steve mentioned, accounts to the problem I observe. Time to switch back to SCHED_4BSD? *sigh* Lucius ___ 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, 2010 at 10:59:43PM +, Alexander Best wrote: > > well i did exactly what they did in the video. watch a 1080p video and move > the output window around while compiling the kernel. > It is trivial to bring ULE to its knees. If you have N cores then all you need is N+1 cpu intensive task. The issue has been known for a few years. http://freebsd.monkey.org/freebsd-current/200807/msg00278.html http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg65839.html -- Steve ___ 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
Lucius writes: > And using "idprio 1 $cmd" as a workaround is, well, a kludge. You have to be root to use idprio, requiring a suid wrapper, which strikes me as kludgy. The worst part is that idprio and rtprio don't entirely work. An idprio process can still interfere with a rtprio process. :-( Rtprio is false advertising, it is *not* real time. Rtprio is really just pigprio. Freddie writes: > As in, if you don't want your make job to hog resources, then use nice > to run it in the background. Doesn't always work. Nice (and rtprio/idprio) only care about CPU usage, not I/O usage. Nice and friends do very little to throttle a process that is hogging I/O resources. Also: Some device drivers (SATA drivers, firewire, perhaps others) hog the CPU for obscene lengths of time, locking out even other device drivers. This causes DATA TO BE LOST. :-( :-( :-( Some SATA drivers still don't support NCQ, causing *horrible* logjams. NCQ also gives 10-13x the speed. ---switch to metadiscussion--- > Also, does this really need to be cross-posted to -current, -hackers, > and -performance? The question is why does cross posting result in receiving duplicates? (Usenet was much better for this type of discussion.) Chuck writes: > I'm also turned off by the attempt to popup a full page ad in > addition to the rest of the advertising content ... > I don't see any value added from these phoronix.com links I haven't tried the link in question, but I skim through phoronix.com using "links -g" and don't get buried in ads. Lately I've been skimming most sites (including phoronix) with images turned off and they load *SO* much faster. ___ 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, 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? -- Alexander Kabaev signature.asc Description: PGP signature
Re: TTY task group scheduling
[ Trim CC a bit] On Thu, Nov 18, 2010 at 06:56:35PM + I heard the voice of Alexander Best, and lo! it spake thus: > On Thu Nov 18 10, Matthew D. Fuller wrote: > > > > 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. > > well...i tried playing back a 1080p vide files while doing `make > -j64 buildkernel` and FreeBSD's interactivity seems far from > perfect. CPU soak against CPU soak isn't really what I meant :) I mean simple stuff like wandering around in a terminal, firing off top's and netstat's, loading up vi's and less's. When I've worked on Linux boxes that were nailed to the wall doing other stuff, that sort of thing got very laggy and inconsistent; similarly loaded FreeBSD boxes always felt much smoother. To be sure, things like competing disk access can be a different story. But I'm talking more CPU suds, and small scheduler tweaks point in that direction too. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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 11/18/10 19:55, Lucius Windschuh wrote: 2010/11/18 Andriy Gapon: [Grouping of processes into TTY groups] Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. But there are serious issue if you use FreeBSD as a desktop OS with SMP and SCHED_ULE, or? Because currently, my machine is barely usable if a compile job with parallelism is running. Movies stutter, Firefox hangs. And even nice -n 20 doesn't do the job in every case, as +20 seems not to be the idle priority anymore?!? And using "idprio 1 $cmd" as a workaround is, well, a kludge. I am not sure if TTY grouping is the right solution, if you look at potentially CPU-intensive GUI applications that all run on the same TTY (or no TTY at all? Same problem). Maybe, we could simply enhance the algorithm that decides if a task is interactive? That would also improve the described situation. Regards, Lucius Stuttering Response, being stuck for over 20 seconds also happens when I start updating the OS' sources via svn. This happens on all boxes, some of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O, doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those phenomena are most seen when you interact with the machine via X11 clients. I think it's hard to realize if a server only does console I/O, but console also seems to be stuck sometimes. It would be worth checking this with some 'benchmark'. X11 in its kind of oldish incarnation on FreeBSD seems to contribute most to those slowdowns, what so ever. ___ 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 11/18/10 19:28, 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 ;) Wishful thinking? ___ 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, 18 Nov 2010 19:55:05 +0100 Lucius Windschuh wrote: > Because currently, my machine is barely usable if a compile job with > parallelism is running. Movies stutter, Firefox hangs. And even nice > -n 20 doesn't do the job in every case, as +20 seems not to be the > idle priority anymore?!? If you're using UFS, I've found it to be quite a bottleneck when doing parallel IO: I even ran a "svn up" in one terminal and tried to login on another a couple of days ago only to find the motd took over 5 seconds to appear! That may be excessive since I was running a kernel with WITNESS and INVARIANTS, but I've found ZFS to be far better if you want good interactivity when reading/writing to disks. -- Bruce Cran ___ 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
[removed current and stable from Cc list] On Thu, 18 Nov 2010 19:55:05 +0100 Lucius Windschuh wrote: > Because currently, my machine is barely usable if a compile job with > parallelism is running. Movies stutter, Firefox hangs. And even nice > -n 20 doesn't do the job in every case, as +20 seems not to be the > idle priority anymore?!? Have you tried increasing kern.sched.preempt_thresh? According to http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/82affa9f195b747d?lnk=raot&fwc=1&pli=1 a good value for desktop use would be 224. -- Bruce Cran ___ 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 11/18/10 10:55 AM, Lucius Windschuh wrote: 2010/11/18 Andriy Gapon: [Grouping of processes into TTY groups] Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. But there are serious issue if you use FreeBSD as a desktop OS with SMP and SCHED_ULE, or? Because currently, my machine is barely usable if a compile job with parallelism is running. Movies stutter, Firefox hangs. And even nice -n 20 doesn't do the job in every case, as +20 seems not to be the idle priority anymore?!? And using "idprio 1 $cmd" as a workaround is, well, a kludge. I am not sure if TTY grouping is the right solution, if you look at potentially CPU-intensive GUI applications that all run on the same TTY (or no TTY at all? Same problem). Maybe, we could simply enhance the algorithm that decides if a task is interactive? That would also improve the described situation. tty grouping is a variant of what we used to have at one stage which is a "kernel schedulable entity group".. KSEG the idea is that all items in a group share some characteristic and some amount of resources. We stripped the KSEG out of the picture because it really complicated the picture. Regards, Lucius ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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, 2010 at 10:56 AM, 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. > > 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. Maybe I'm just a lowly user and don't fully understand the issue, but isn't this the whole reason for having /usr/bin/nice installed? As in, if you don't want your make job to hog resources, then use nice to run it in the background. How does the work on the geom_sched (for I/O scheduling) play into this? Am I missing something fundamental to the issue in question? Also, does this really need to be cross-posted to -current, -hackers, and -performance? -- Freddie Cash fjwc...@gmail.com ___ 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 Nov 18, 2010, at 10:23 AM, Alexander Best wrote: > On Thu Nov 18 10, Andriy Gapon wrote: >> on 18/11/2010 13:04 O. Hartmann said the following: >>> On 11/18/10 02:30, grarpamp wrote: Just documenting regarding interactive performance things. This one's from Linux. http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>> >>> Well, >>> it would be nice to have those improvements in FreeBSD, but I doubt this >>> will make >>> it in due time to FreeBSD's kernel. >> >> Well, I think that those improvements apply only to a very specific usage >> pattern >> and are greatly over-hyped. > > you think so? judging from the videos the changes are having a huge impact > imo. > > cheers. > alex > > btw: i posted a similar thread on freebsd-backers@, but nobody seemed > interested in it. subject line is "sched_autogroup_enabled". I attempted to find reliable benchmarks or even an idea as to what they thought they were measuring, because a sentence like the following: Tests done by Mike show the maximum latency dropping by over ten times and the average latency of the desktop by about 60 times. ...isn't mathematically possible, I'm pretty sure. Frankly, I'm also turned off by the attempt to popup a full page ad in addition to the rest of the advertising content which surrounds what is nominally supposed to be the real content. That doesn't mean there is anything wrong with the patch or the notion of adjusting the scheduler, but I don't see any value added from these phoronix.com links. Regards, -- -Chuck ___ 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
2010/11/18 Andriy Gapon : > [Grouping of processes into TTY groups] > > Well, I think that those improvements apply only to a very specific usage > pattern > and are greatly over-hyped. But there are serious issue if you use FreeBSD as a desktop OS with SMP and SCHED_ULE, or? Because currently, my machine is barely usable if a compile job with parallelism is running. Movies stutter, Firefox hangs. And even nice -n 20 doesn't do the job in every case, as +20 seems not to be the idle priority anymore?!? And using "idprio 1 $cmd" as a workaround is, well, a kludge. I am not sure if TTY grouping is the right solution, if you look at potentially CPU-intensive GUI applications that all run on the same TTY (or no TTY at all? Same problem). Maybe, we could simply enhance the algorithm that decides if a task is interactive? That would also improve the described situation. Regards, Lucius ___ 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, 2010 at 10:39, Chuck Swiger wrote: > Frankly, I'm also turned off by the attempt to popup a full page ad in > addition to the rest of the advertising content which surrounds what is > nominally supposed to be the real content. That doesn't mean there is > anything wrong with the patch or the notion of adjusting the scheduler, but I > don't see any value added from these phoronix.com links. Most stuff on Phoronix is of dubious value, and they have outright lied about stuff in the past, in order to drum up advertising business (such as Steam on Linux, which Value has consistently said isn't happening). -- Rob Farmer ___ 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, 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, 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 ;) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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 18/11/2010 13:04 O. Hartmann said the following: > On 11/18/10 02:30, grarpamp wrote: >> Just documenting regarding interactive performance things. >> This one's from Linux. >> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > Well, > it would be nice to have those improvements in FreeBSD, but I doubt this will > make > it in due time to FreeBSD's kernel. Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. P.S. What is the due time, BTW? -- Andriy Gapon ___ 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 11/18/10 02:30, grarpamp wrote: Just documenting regarding interactive performance things. This one's from Linux. http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 Well, it would be nice to have those improvements in FreeBSD, but I doubt this will make it in due time to FreeBSD's kernel. ___ 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"
