Original from  IVAN TODOROSKI  to DENIS TONN on 11-20-1998
Original Subject: Guess who's back... ;)

                         ---------------------------------------

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

 Well.. My excuse is just that I am busy at the moment.. I won't have 
a lot of time to read/reply (or think about the questions) for the 
next while either.. I'll spend a little time with this one, but then I
gotta get back to work.. 

  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:
 
IT> Where can this "Warp Debug Handbook" be found?

 Should be on the OS/2 developers web site somewhere.. You can order 
the 4 volume set in hardcopy (IBM pubs number SBOF-8617), but the INF 
on the web site is being updated while the hardcopy is pretty static.
Look for a file called SG244640.ZIP (or similar). This is the "pubs" 
number of the first volume of the 4 volume set (but the INF includes 
all 4 volumes!). 


  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
                        ^^^^^^^^^^^^^^^^
IT>    Is this the boost that is controled by PRIORITY_DISK_IO?

 No.. PRIORITY_DISK_IO relates to Disk operations controlled by 
OS2DASD.DMD. The DMD will "organize" disk seeks in order to minimize 
head movement. This statement will cause the "foreground" app to have 
it's disk I/O request moved to the top of the queue, regardless of how
it affects the total head movement. It is another parm intended to 
maximize the "user's active app" response. 

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

 The only information I have on that is:
  Window affects a single thread.
  Keyboard affects all threads in a process.
  Foreground affects all threads in a screen group (implying full 
screen sessions). 

 In the context of PM, I would suspect that window boost is used for 
the active message queue receiver thread. 

  DT>    0x80           VDM Simulated Interrupt.
  DT>   TCBPriorityMin
  DT>    The minimum allowed priority. Normally 0 but set when priority
  DT>    inversion becomes a possibility.
 
IT>   And also, is there a way to modify the values of these TCBPriClassMod
IT>   boosts by poking inside the kernel? I simply live to experiment and
IT>   fiddle with things! ;)

 Not that I have found. This is done by various places (where the 
thread behaviour is "detected") in the kernel. 

  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.
 
IT>   Just to make sure I understood you:
IT> 
IT>  Priority = TCBPrilevel OR PrioTable[ TCBPriClass OR TCBPriClassMod ]

 TCBPriClass = Idle, Normal, Server, TimeCrit
 TCBPriLevel = Delta within the particular group above (00-1F)
 TCBPriClassMod = the observed "behaviour" of the particular thread. 

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

 Yep.. And is one of the areas where changing it around will cause 
some race conditions (WPS, Netbios, and LAN interaction). It doesn't 
make sense to me either.. 

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

 Yes and no. The above table is used on SMP systems as well as Uni 
systems. I would guess that they started from a "logicly" laid out 
table and manually tuned it (empirically) for best/prefered response 
time, and then further tuned it to eliminate some race conditions 
(both SMP and Uni systems). 
 
 Your above noted point is one "tuning" that I investigated (and have 
reported the race condition). I also disagree with the degree of boost
that a I/O bound app gets. The table allows for the possibility of a 
thread that is both CPU *and* Disk intensive to overide a starved 
thread boost (which where I focused on in my testing). 

[..]

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

 I see those messages. I'll try and respond to them too (later), but I
note one point that you should consider:
 The app (or PM on the app's behalf) will end up "calling" the video 
driver multiple times for a single "operation". On each exit from an 
API call the scheduler will check for the "highest priority ready 
thread". This may result in a thread switch, but the thread that is
"updating" at that time may *still* be the highest priority thread.
The driver may not be preemptable, but the app will enter and leave
the driver many times in sequence (and therfore the APP may or not be 
preempted based on it's priority). The behaviour you observe will need
to take that into consideration. 

  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.
 
IT>   I don't understand either of them... What does "voluntary
yield" and
IT>   "window boost" actually mean?

 See above for Window boost. Voluntary yield is a sleep or other API 
that causes the thread to be blocked for a period of time (sems, 
etc) based upon code in the app. Contrast with being preempted (round
robin or higher priority thread ready). 
 I still don't have the source, but I received the above from someone 
that took a quick look at the code.. In that case, I don't see the 
place to tune a "well behaved" thread boost. Might be in a direct code
path somewhere (or duplicated with another "behaviour"). 

  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".
 
IT>   Hmm... gets better all the time! The scheduler is so extremely strict
IT>   and precise in its timing and timeslice assignment, that this could
IT>   endanger the stability of the whole system! What if a Time Critical
IT>   thread suddenly goes berserk in a tight loop without any API calls?

  Yup.. The system will be "hung". This in one of the reasons 
that high priority threads should be used carefully, and have lots of 
voluntary yield points. 

IT>   The above table indicates that the starvation boost isn't enough to
IT>   preempt Time Critical threads, so even though technicaly the system
IT>   hasn't crashed, it will be useless for all purposes and would have to
IT>   be rebooted :(

 Yep.. Or better yet, get a system dump so you can analyze and nail 
the sucker. 

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

 Not really. The "system" supplies functionalty for the programmer 
(device driver, application, or whatever). I have yet to work on *any*
system (where I have total access to everything!) whereby I cannot 
"crash" or "hang" the system. The mainframe world gets
real close to
unbreakable with the system console, but even there it is not 100% 
(but it is 99.9999% or better). There is no "system console" in the 
OS/2 (or desktop) environment. 

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

 Don't worry overly much about it. If they were prone to "looping" 
frequently, we would probably know about it by now (via a dump and 
analysis). There is usually a reason for a TC thread, and they tend to
be very well behaved (frequent voluntary yield). They are also very 
easy to spot in a system dump or a kernel debug session.. 

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

 Not quite sure what you are seeing here. I don't see that here, or 
in any dumps I have looked at. Is it possible that this is an artifact
of priority commander, or whatever tool you are using to view process
threads and priority with? What does PSTAT say for your system? 

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

 The kernel is pretty stable and pretty well tuned to prevent "long 
running" non-preemptable code paths (realize that "long running" is 
subject to interpretation). Also realize that a thread will be 
"blocked" if the kernel (or device driver) finds that it cannot 
complete the requested operation immediately (I/O, SemWait, etc). In 
that case another thread is selected and dispatched. 
 Not all API's enter Kmode, some don't even enter ring 0 (and are 
completely supported in DOSCALL1.DLL or other DLL's). 
 The code path throughout the kernel is pretty well thought out to 
minimize the amount of time it spends in "non-preemptable" code. 

IT>    Please, I would LOVE to mess with it! I'm running Warp 4 GA, and by
IT>    grep-ing the kernel for words like "version",
"revision" etc. I found
IT>    this string inside:
IT> 
IT>       Internal revision 9.023, 95/11/07
IT> 
IT>   I hope this is enough to identify my kernel. I wonder why this string
IT>   exists in human readable form inside the kernel, since the kernel is
IT>   compressed?

 You said it right there, it is "human readable" because there are 
lots of times that "humans" do read it - with the simplest of tools. 

  DT> Hint: LXLite to unpack the kernel and the above table is a direct
  DT> lift from a kernel data area.
 
IT>      Yup... found it! Thanks for the tip. Gonna go poking it now, and
IT>      will return with results.
IT> 
IT>   If this info you were planning on sending to me was the location of
IT>   this table, then don't bother, since I found it, but if there was
IT>   something else too, please send it.

 It appears from your other message that you have found out all you 
ned to know (and most of what I found). 

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

 See above. From the OS/2 developers web site. 


   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
 

 



--- Maximus/2 3.01