Re: scheduler (sched_4bsd) questions

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 09/20/04

  • Next message: John Baldwin: "Re: scheduler (sched_4bsd) questions" 
    To: Stephan Uphoff <ups@tree.com>
Date: Mon, 20 Sep 2004 14:42:04 -0400

    On Saturday 18 September 2004 07:08 pm, Stephan Uphoff wrote:
    > On Sat, 2004-09-18 at 16:53, 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.
    >
    > Lower priority than the interrupt threads.
    > They can however have a priority better than the interrupted thread
    > holding the kernel resource.
    > In this case the newly awoken threads will be next to run.
    > If they are compute bound in user space or wake other threads with
    > better priorities it might take a while until the system switches back
    > to the interrupted thread.

    Yes, but that is what the system is supposed to do. If you want the
    interrupted thread to run sooner because it holds a resource, then you need
    to adjust its priority when it holds the resource somehow. We do this with
    mutexes by having a blocking thread lend its priority to the owner of the
    mutex. 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
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: John Baldwin: "Re: scheduler (sched_4bsd) questions"

    Relevant Pages

    • Re: scheduler (sched_4bsd) questions
      ... >> Lower priority than the interrupt threads. ... >> They can however have a priority better than the interrupted thread ... >> holding the kernel resource. ... This could be accomplished my adjusting the priority on trap entries to ...
      (freebsd-arch)
    • Re: Month by month resource leveling results in overallocated reso
      ... And what if a resource truly is only ... Your practice of assigning at a 70% level means that when you look ... (Though the priority explanation was as I expected it...thanks for the ... does the priority of the summary task affect it at ...
      (microsoft.public.project)
    • Re: Month by month resource leveling results in overallocated reso
      ... Your practice of assigning at a 70% level means that when you look at a plan that has Bill assigned to a task that shows a duration of 8 hours, starting Monday at 8am and ending at 5pm, it really means that Bill will work on it for 6 hours sometime between 8 and 5. ... But those records rarely detail hour by hour what the resource was doing - you know it took Bill about a week last year but you don't have a step by step record of his day, merely the fact he worked on it during the second week of March. ... should never have resources assigned to them, their priority settings are ... does the priority of the summary task affect it at> all? ...
      (microsoft.public.project)
    • Re: Month by month resource leveling results in overallocated resource
      ... But since summaries are a:reports, not physical work activities; and b: should never have resources assigned to them, their priority settings are meaningless. ... I'm confused as to your resource availability setting as you described it in your intial post - I'm wondering if this has something to do with your issue. ... A 70% assignment means that when the resource is working on something for a solid 8 hour day, for some reason they can only generate the amount of work that would normally only require about 6 hours to complete. ... does the priority of the summary task affect it at all? ...
      (microsoft.public.project)
    • Re: Month by month resource leveling results in overallocated reso
      ... I guess I've really been confused on the resource availability bit. ... should never have resources assigned to them, their priority settings are ... A 70% assignment means that when ... does the priority of the summary task affect it at all? ...
      (microsoft.public.project)