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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TTY task group scheduling
On 11/19/10 16:49, Taku YAMAMOTO wrote: 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; If I read it correctly, now instead of the slice given to the thread being always sched_slice, now it is reduced to a value smaller than sched_slice based on how long did the thread sleep? How does that help? 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); } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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
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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TTY task group scheduling
On Thu Nov 18 10, Rob Farmer wrote: > 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). so we need a trusted source to check whether the impact of the ~200 line patch as claimed by phoronix remains valid. can anybody test this? or provide links to independant benchmark results? cheers. alex > > -- > Rob Farmer -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TTY task group scheduling
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". > > P.S. What is the due time, BTW? > > -- > Andriy Gapon -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
