TTY task group scheduling

[Alexander Best]

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<kabaev at gmail.com>  
> >>wrote:
> >>>On Thu, 18 Nov 2010 18:56:35 +0000
> >>>Alexander Best<arundel at freebsd.org>  wrote:
> >>>
> >>>>On Thu Nov 18 10, Matthew D. Fuller wrote:
> >>>>>On Thu, Nov 18, 2010 at 06:23:24PM +0000 I heard the voice of
> >>>>>Alexander Best, and lo! it spake thus:
> >>>>>>judging from the videos the changes are having a huge impact imo.
> >>>>>Well, my (admittedly limited, and certainly anecdotal) experience is
> >>>>>that Linux's interactive response when under heavy load was always
> >>>>>much worse than FreeBSD's.  So maybe that's just them catching up to
> >>>>>where we already are   ;)
> >>>>well...i tried playing back a 1080p vide files while doing
> >>>>`make -j64 buildkernel` and FreeBSD's interactivity seems far from
> >>>>perfect.
> >>>One thing that just begs to be asked: since when decoding 1080p became
> >>>an interactive task?
> >>>
> >>Strictly speaking it isn't - but displaying it is a timing-sensitive
> >>task that isn't CPU- or I/O-bound, and scheduling-wise that probably
> >>makes it more like the "fast response when woken up" interactive tasks
> >>than a CPU-bound non-interactive process.
> >>Decoding it into another file on the disk is in the latter category,
> >>of course - but I don't think that's what he meant. :)
> >>
> >>More on topic - while this was a tiny patch for Linux, it seems like
> >>it would take more work for us, since I don't believe either of the
> >>schedulers handles task groups in the required way. The linux patch
> >>was just "create task groups automatically", since they already had
> >>some suitable logic for scheduling based on task groups in their CFS
> >>scheduler. We would have to (re-)add that first, which is non-trivial.
> >personally i think freebsd would hugely benefit from a scheduler framework
> >such as geom/gsched, where it's easy to switch between various algorithms.
> >
> >that way it be much easier to try out new concepts without having to write 
> >a
> >completely new scheduler.
> 
> 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