Re: cvs commit: src/sys/kern sched_ule.c

From: Julian Elischer (julian_at_elischer.org)
Date: 12/13/04

  • Next message: Maxim Sobolev: "Re: GBDE write performance really sucks" 
    Date: Mon, 13 Dec 2004 11:17:37 -0800
To: Scott Long <scottl@freebsd.org>, John Baldwin <jhb@freebsd.org>, Jeff Roberson <jeff@FreeBSD.org>, Peter Wemm <peter@freebsd.org>, Stephan Uphoff <ups@tree.com>, FreeBSD Current <freebsd-current@freebsd.org>

    The whole problem that "slots" is trying to solve is to stop a single
    process
    from being able to flood the system with threads and therefore make the
    system
    unfair in its favour.

    The "slots" method is really suitable for the 4bsd scheduler but it is
    really
    not so good for ULE (at least I think that there are probably better
    ways that
    ULE could implement fairness).

    What I think should happen at this stage is that the inclusion of
    kern_switch.c
    should be replaced by actually copying the contents of that file into
    the two
    schedulers and that they be permitted to diverge. This would allow ULE and
    BSD to be cleaned up in terms of the sched_td/kse hack (where they are in
    fact the same structure, but to keep diffs to a minimum I defined one in
    terms of the other with macros).

    It would also allow jeff to experiment absolutly freely on how ULE might
    implement fairness without any constraints of worrying about the BSD
    scheduler, and visa versa.

    I have been hesitant to do this because there was some (small) amount of
    work going on in the shared file, but I think it is time to cut the
    umbilical
    cord. If ULE is really fixed then this would be a good time to break
    them apart,
    and delete kern_switch.c (or at least move most of the stuff in it out
    to the
    two schedulers). This would protect ULE from future problems being
    "imported" from BSD for example.

    comments?

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Maxim Sobolev: "Re: GBDE write performance really sucks"

    Relevant Pages

    • Re: cvs commit: src/sys/kern sched_ule.c
      ... Certainly if ULE were to implement ... >>What if a scheduler wants to keep a thread on TWO lists.. ... >>thread on BOTH teh percpu queue and an independent queue. ...
      (freebsd-current)
    • Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
      ... That way the scheduler peeps can feed this into schedgraph.py (and you ... re-appear even using ULE. ... Whereas switching to 4BSD the same servers got into high-load ... What's about playing AVIs and using other GUIs, key word here and for ULE in general is interactivity. ...
      (freebsd-current)
    • Re: Big problems with 7.1 locking up :-(
      ... We've since then compiled the kernel under the BSD scheduler to rule that out, ... FWIW, the other guy I know who is having this problem had already switched to using ULE under 7.0-release, and did not have any problems with it. ... Scheduler changes always come with some risk of exposing bugs that have existed in the code for a long time but never really manifested themselves. ... and the lockups occur in high disk-I/O situations. ...
      (freebsd-stable)
    • Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
      ... That way the scheduler peeps can feed this into schedgraph.py (and you ... You might also try switching to SCHED_ULE to see if it helps. ... re-appear even using ULE. ... same scenario on 8.x systems used as web servers. ...
      (freebsd-current)
    • Re: cvs commit: src/sys/kern sched_ule.c
      ... >>ULE could implement fairness). ... >>implement fairness without any constraints of worrying about the BSD ... What if a scheduler wants to keep a thread on TWO lists.. ... thread on BOTH teh percpu queue and an independent queue. ...
      (freebsd-current)