On Saturday, 14 November 1998,
     DENIS TONN wrote to IVAN TODOROSKI about Guess who's back... ;)

  Sorry about this late reply, I had some problems with uploading my
  mail...

IT>>      It's about PRIORITIES

 DT> [...]

 DT> OK.. I'll take a crack at it.. I won't attempt to answer each of
 DT> your questions individually at this time. What I will do is
 DT> describe the way it works, and hopefully that will answer some of
 DT> your questions. After that we can get into specifics.

       Thanks for your reply. I appreciate it!

 DT> OK.. To start things off, there are 2 "flavors" of priority
 DT> adjustment. ABSOLUTE and DYNAMIC. Absolute means that whatever the
   [...]
 DT> The above describes the behaviour with PRIORITY=ABSOLUTE
 DT> specified, and is also affected by the second (y) value of
 DT> TIMESLICE=x,y.
   [...]
 DT> The first value (x) on the TIMESLICE parameter also affects this,
 DT> in that it controls how long the timeslice of a "boosted" thread
 DT> should be. In effect, there can be 2 different "timeslice"
 DT> lengths, one for "normal" (round robin) operation and one for
 DT> dynamicly "boosted" threads.

  The documentation is very unclear on this parameter. Thanks for
  explaining its meaning.

 DT> The following table (lifted from the Warp Debug Handbook) shows
 DT> the values used by the scheduler in it's "boosting" for the
 DT> internal OS/2 dispatcher priority table:

        Where can this "Warp Debug Handbook" be found?

 DT>  -----------------------------------------------------------------
 DT>   TCBPriLevel
 DT>    The priority delta which may range from 0x00 to 0x1f.
 DT>   TCBPriClassMod
 DT>    The priority boosts which may be any of the combined values:
 DT>    0x04           Keyboard Boost
 DT>    0x08           CPU Starvation Boost
 DT>    0x10           Device I/O Boost
                       ^^^^^^^^^^^^^^^^
   Is this the boost that is controled by PRIORITY_DISK_IO?

 DT>    0x20           Foreground Boost
 DT>    0x40           Window Boost
                       ^^^^^^^^^^^^^
 I understand all the boosts except this one. When does this one happen?

 DT>    0x80           VDM Simulated Interrupt.
 DT>   TCBPriorityMin
 DT>    The minimum allowed priority. Normally 0 but set when priority
 DT>    inversion becomes a possibility.

  And also, is there a way to modify the values of these TCBPriClassMod
  boosts by poking inside the kernel? I simply live to experiment and
  fiddle with things! ;)

 DT>  Priority is calculated by forming an index by ORing TCBPriClass and
 DT> TCBPriClassMod and reading a constant value from the priority table.
 DT> The low byte of this is then further ORed with the TCBPriLevel.

  Just to make sure I understood you:

 Priority = TCBPrilevel OR PrioTable[ TCBPriClass OR TCBPriClassMod ]

  Is this correct?

 DT> +----------------------------------------------------------------------+
 DT> |Starved         08 --------------------------------------------------+|
 DT> |Device I/O      10 -------------------------------------------------+||
 DT> |Foreground      20 ------------------------------------------------+|||
 DT> |Window          40 -----------------------------------------------+||||
 DT> |VDM Interrupt   80 ----------------------------------------------+|||||
 DT> |============================================================     ||||||
 DT> |Not Keyboard (04)             | Keyboard (04)                    ||||||
 DT> |Server  Idle    Regular TC    | Server  Idle    Regular TC       IWFDS|
 DT> |0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// -----|
 DT> |0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// ----S|
 DT> |0x72f,  0x100,  0x71f,  0x800,| 0x72f,  0x100,  0x71f,  0x800,// ---D-|
 DT> |0x72f,  0x100,  0x71f,  0x800,| 0x72f,  0x100,  0x71f,  0x800,// ---DS|
 DT> |0x300,  0x100,  0x300,  0x800,| 0x300,  0x100,  0x400,  0x800,// --F--|
                                      ^^^^^           ^^^^^
                This is the only situation where Regular exceeds Server.

   By simply looking at this table, I can't find any particular law or
   pattern by which these values are assigned. Were they empiricaly
   determined?

  I understand completely now how the priority assignment works. Took me
  a while to figure out this table, because it is layed out a little
  odd, but I finaly got it. Thanks for this valuable information.

 DT> |0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// --F-S|
 DT> |0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// --FD-|
 DT> |0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// --FDS|
 DT> |0x500,  0x100,  0x500,  0x800,| 0x500,  0x100,  0x500,  0x800,// -W---|
 DT> |0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// -W--S|
 DT> |0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -W-D-|
 DT> |0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -W-DS|
 DT> |0x500,  0x100,  0x500,  0x800,| 0x500,  0x100,  0x500,  0x800,// -WF--|
 DT> |0x62f,  0x100,  0x61f,  0x800,| 0x62f,  0x100,  0x61f,  0x800,// -WF-S|
 DT> |0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -WFD-|
 DT> |0x74f,  0x100,  0x73f,  0x800,| 0x74f,  0x100,  0x73f,  0x800,// -WFDS|
 DT> +----------------------------------------------------------------------+
 DT>
 DT>   Notes:
 DT>  VDM Simulated interrupts always result in a value of 0x800
 DT>  Foreground server class is not affected by the keyboard boost.
 DT>  Time-critical class is not affected by any boosts.
 DT>  Idle class is not affected by any boosts.
 DT>  By examining the priority table it is clear that idle class will
 DT>   always be pre-empted by any other class.
 DT>  Time-critical class can never be pre-empted by any other class.
 DT>  Time-critical threads can only be pre-empted by other time-critical
 DT>   threads with a higher delta.
 DT>  Server and Regular class threads may pre-empt each other depending on
 DT>   priority boosts and delta.
 DT>  -----------------------------------------------------------------

  I now realize and appreciate the priority policy, but there are still
  things I cannot explain concerning PM drawing operations. I'll
  elaborate what I mean in one of my following messages, after I do some
  more experiments.

 DT>  My Notes:
 DT> I believe the "voluntary yield" is really the
"window boost" in
 DT> the above. At least that is the behaviour I have seen in dumps and
 DT> kernel debug sessions. I need the source code to be sure.

  I don't understand either of them... What does "voluntary yield" and
  "window boost" actually mean?

 DT>  You should keep in mind that the dispatcher will "check"
the queue of
 DT> "ready to run threads" more frequently than just at the end of a
 DT> timeslice.
 DT> For example, a hardware interrupt may make a higher priority
"blocked"
 DT> thread become ready. The dispatcher can detect this before the end of a
 DT> timeslice, and "preempt" the current thread before the end of it's
 DT> "timeslice".

  Hmm... gets better all the time! The scheduler is so extremely strict
  and precise in its timing and timeslice assignment, that this could
  endanger the stability of the whole system! What if a Time Critical
  thread suddenly goes berserk in a tight loop without any API calls?
  The above table indicates that the starvation boost isn't enough to
  preempt Time Critical threads, so even though technicaly the system
  hasn't crashed, it will be useless for all purposes and would have to
  be rebooted :(

  Unless of course you have WatchCat or simmilar monitor which runs at
  maximum possible priority 0x81f (Time Critical, delta 31) to bail you
  out of it. But such monitor doesn't come by default, so the system is
  inherently "instable" (or should I say "too stable").

  In light of this, I recently discovered that there are more Time
  Critical threads runing in my system than I feel comfortable with.

  It turns out that EVERY text-mode (VIO or FS) program has actually 2
  threads, even if it's single-threaded! And this second thread always
  runs at MAXIMUM (0x81F) priority! If it decides to screw up, there
  wont be much you can do to stop it... What's the deal with these
  threads, what is their purpose???

 DT>  There is one more thing worth mentioning here, threads that have entered
 DT> "Kmode" are not preemtable. This means that a device
driver "loop" cannot
 DT> be preempted - even by a higher priority thread. This is quite distinct
 DT> from "hardware interruptable", which is controlled via
the STI/CLI CPU
 DT> instructions.

  I saw you mentioning this Kmode in a discussion with JdeBP, and I've
  been meaning to ask about this. How much of the operating system runs
  in this Kmode, and are there any long sequences of it which could
  interfere with the smooth multitasking? Does every API call involve
  some amount of non-preemtable Kmode code in it?


 DT> OK.. This should be enough to set the stage. Feel free to ask
 DT> questions. I will answer to the best of my ability. All this is

   Oh yeah! More than enough...

 DT> really undocumented, and subject to changes at any time (even
 DT> fixpacks). There have not been any changes to the basic concepts
 DT> for quite a while though. If you really feel the need, I can

    Well nothing in life is permanent... ;)

 DT> describe how you can "patch" the kernel to play with the boosting
 DT> values in the above table. Let me know what version (and FP level)
 DT> of the kernel you want to play with.  I have played with it some,
 DT> but it does tend to expose some race conditions, especially in the
 DT> shell. You are on your own if you mess with it.

   Please, I would LOVE to mess with it! I'm running Warp 4 GA, and by
   grep-ing the kernel for words like "version",
"revision" etc. I found
   this string inside:

      Internal revision 9.023, 95/11/07

  I hope this is enough to identify my kernel. I wonder why this string
  exists in human readable form inside the kernel, since the kernel is
  compressed?

  Also could you give the info on the FP8 kernel too? I'm gonna apply
  FP8 soon...

 DT> Hint: LXLite to unpack the kernel and the above table is a direct
 DT> lift from a kernel data area.

     Yup... found it! Thanks for the tip. Gonna go poking it now, and
     will return with results.

  If this info you were planning on sending to me was the location of
  this table, then don't bother, since I found it, but if there was
  something else too, please send it.

P.S. I *MUST* get my hands on that "Debug Handbook" of yours! :)

                                                            - Ivan -

.!. Confucius say: "Man who abuse his computer get bad bytes!"
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ