Re: scheduler (sched_4bsd) questions

From: Julian Elischer (julian_at_elischer.org)
Date: 09/21/04

  • Next message: Bruce M Simpson: "Re: Global (non _KERNEL) place for sockaddr_union?" 
    Date: Mon, 20 Sep 2004 18:02:27 -0700
To: John Baldwin <jhb@FreeBSD.org>

    >
    >
    >On Sunday 19 September 2004 03:10 am, Julian Elischer wrote:
    >
    >
    >>John Baldwin wrote:
    >>
    >>
    >>>On Saturday 18 September 2004 01:42 pm, Stephan Uphoff wrote:
    >>>
    >>>
    >>>>On Fri, 2004-09-17 at 21:20, Julian Elischer wrote:
    >>>>
    >>>>
    >>>>>Stephan Uphoff wrote:
    >>>>>
    >>>>>
    >>>>>>If this is true kernel threads can be preempted while holding
    >>>>>>for example the root vnode lock (or other important kernel
    >>>>>>resources) while not getting a chance to run until there are no more
    >>>>>>user processes with better priority.
    >>>>>>
    >>>>>>
    >>>>>This is also true, though it is a slightly more complicated thing than
    >>>>>that.
    >>>>>Preempting threads are usually interrupt threads and are thus usually
    >>>>>short lived,.
    >>>>>
    >>>>>
    >>>>But interrupt threads often wake up other threads ...
    >>>>
    >>>>
    >>>That are lower priority and thus won't be preempted to. Instead, they
    >>>run when the interrupt thread goes back to sleep after it finishes.
    >>>
    >>>
    >>though that may still be before the original preempted thread gets run..
    >>
    >>that reminds me..
    >>John, we should add a flag to setrunqueue to add a preempted thread back at
    >>the FRONT of it's runqueue.. So that it gets a chance to use the rest of
    >>its slot..
    >>
    >>
    >
    >The scheduler can already detect this by noting that curthread is being passed
    >to sched_add() when it has quantum left and then put it at the head of the
    >queue for its priority but only with the remaining quanta. This only really
    >works for schedulers that actually track quanta, i.e., not 4BSD. Given that,
    >I think the scheduler is free to implement this how it chooses and doesn't
    >require another flag to setrunqueue().
    >

    Just for kicks I implemented this in my p4 branch to see if it would help the problem
    with atapi cdroms failing to work when premption is turned on..

    but it didn't help..

    (it's a very strange problem.. turning on preemption makes my test machine's cdrom
    time out so much in boot that it takes 5 minutes to probe during boot.)

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

  • Next message: Bruce M Simpson: "Re: Global (non _KERNEL) place for sockaddr_union?"