On Tuesday 22 June 2004 08:07 pm, Julian Elischer wrote: > hmmmm so, how do we give them a priority that is not in the same range a > user processes, and separate from each other when the scheduler > may not use run queues as seen in sched_4bsd.? > > using the magic number RQ_PPQ is not "kosher". > with a different scheduler that may not exist. > > On Tue, 22 Jun 2004, Bosko Milekic wrote: > > Julian Elischer wrote: > > >On Tue, 22 Jun 2004, John Baldwin wrote: > > > > ... > > > > >> That was the intention. One question though, if the ithreads aren't > > >> on the system run queues then which run queues are they on? > > > > > >aren't they run from the interupt? > > > > Not always. They have to be put on a runqueue if they block on a > > mutex, say. > > > > -Bosko In theory the thread priorities are scheduler independent. At least the values with respect to each other. I think I like Bruce's idea as far as removing knowledge of RQ_PPQ from non-scheduler code. The schedulers can easily check for realtime kernel threads (currently just ithreads) and map that to an appropriate priority on its backing queues and allow us to compress the ithread priority space, maybe down to 16 or 32 priorities. /* * Priorities range from 0 to 255, but differences of less then 4 (RQ_PPQ) * are insignificant. Ranges are as follows: * * Interrupt threads: 0 - 63 * Top half kernel threads: 64 - 127 * Realtime user threads: 128 - 159 * Time sharing user threads: 160 - 223 * Idle user threads: 224 - 255 * * XXX If/When the specific interrupt thread and top half thread ranges * disappear, a larger range can be used for user processes. */ -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Wed Jun 23 2004 - 13:03:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC