Original from  IVAN TODOROSKI  to DENIS TONN on 12-01-1998
Original Subject: Poking inside the kernel

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

IT>   Well I tried to do my best to isolate and take into consideration all
IT>   these effects.
IT>   Just consider the following results:
IT> 
IT>   In all cases the priority of the PMSHELL threads was set to Regular,
IT>   delta 0 (checked, re-checked, triple-checked), so this source is
IT>   eliminated.

 Both copies of PMShell? If not, which one? Keep in mind that 
"PMSHELL.EXE" is really just a "driver" for a bunch of
functions in 
DLL's and the processes are quite different depending on which 
functions (and therefore DLL's) are required. The first "copy" (PID) 
of PMSHELL.EXE in memory is for PM functions, the second copy is for 
the Workplace Shell functions (user interface).  

IT>   Non-preemptivity of driver operations has no observable effect here
IT>   because if you raise the priority of the background process to Time
IT>   Critical it won't freeze, it WON'T EVEN SLOW DOWN, not even a little,
IT>   when you drag other windows around. So some portions of the redrawing
IT>   of the window surely are non-preemptive, but they're so finegrained
IT>   that the effect is negligible. If the non-preemptivity of driver
IT>   operations was the major reason for this freezing, then changing the
IT>   priority of the background process would not have changed a thing, but
IT>   it did.
IT> 
IT>   So, what did I do?
IT> 
IT>   Remember, all threads of PMSHELL.EXE are set to Regular, delta 0 in
IT>   the following experiments.
IT> 
IT> 1)  Default kernel, PRIORITY=ABSOLUTE
IT>        Applications freeze when you drag windows around.
IT> 
IT> 2)  Default kernel, PRIORITY=DYNAMIC
IT>        Applications freeze when you drag windows around.
IT> 
IT> 3)  "Flat" kernel, PRIORITY=ABSOLUTE
IT>        Applications freeze when you drag windows around.
IT> 
IT> 4)  "Flat" kernel, PRIORITY=DYNAMIC
IT>        Applications *DON'T* freeze when you drag windows around.
IT> 
IT> 
IT>     What conclusions would you draw from this?

 IT>>   The conclusion is that PM drawing operations get a priority boost,
 IT>>   even when PRIORITY=ABSOLUTE, and that's why they run at higher
 IT>>   priority than the calling program.
 
  DT>  No, the PM drawing threads do NOT get "boosted". They
may be setting
  DT> themselves to a higher level (temporarily) or passing off the work to
  DT> high priority threads (more likely), but they are NOT boosted with
  DT> PRIORITY=ABSOLUTE.
 
IT>   Maybe so, maybe it's not an actual "boost", but all
other things being
IT>   equal, drawing operations do have a higher priority in case 1) then in
IT>   case 4) above. So cases 1) and 4) are not totally equivalent, which
IT>   means that setting PRIORITY=ABSOLUTE is NOT the same as
"flattening"
IT>   the kernel priority table. How else could these 4 experiments be
IT>   explained?

 I don't know how to explain this just yet, but let me try to add a 
few details that might help.. 

 - PM "drawing" happens on the thread of the application, and 
therefore happens at the priority of the thread calling PM to "draw".
 - When the thread enters the video driver, it may become 
non-preemptable for the duration of the driver call, but as soon as it
leaves the driver it becomes a candidate for preemption. This does NOT
mean it will be preempted, just that it is possible. If it is *still*
the highest priority thread, then it will be immediately dispatched
again. 
 - Not all dynamic boosting happens via the priority table in the 
kernel. VDM simulated interrupt is the only one of these I know of, 
but there may be others. 


  DT>  Your experiments in this area are doing more to expose the behaviour
  DT> of PM and the graphics driver than they are in exposing the behaviour
  DT> of priority adjustment. Keep this FIRMLY in mind with the above "test
  DT> scenerio".
  DT>  If you wish to actually play with testing the priority boosting of
  DT> the kernel, you need to eliminate these variables from your
  DT> experiments.
 
IT>   Well ALL things are equal, only things that are varied is the PRIORITY
IT>   setting and the kernel priority table.
IT> 
IT>   And I did some of those tests with applications and threads you
IT>   proposed (I was using OREXX, not C, but it souldn't matter, since
IT>   OREXX has a RexxUtil function to set the priority), and everything
IT>   works absolutely as expected, there seem to be no anomalies in the
IT>   priority scheduler, which puzzles me even more!

 I think if we look at what happens when you drag a window around, it 
might help. I don't think it will explain everything, but some of it. 
It is hard for me to independently verify (or recreate for analysis) 
your results, or to design and test an "experiment" here to
demonstrate. I don't have a slow enough system to exhibit the 
symptoms as your does. 

 Dragging a window in "full window dragging" does 2 things. It 
generates a LOT of repaint messages. Not only to the app that is being
dragged, but to the underlying windows (including the WPS) that are 
being covered and uncovered. The CPU will be QUITE busy generating, 
and then handling these messages (and running the video driver code to
do the screen updates). 
 Throw in the fact that the window being dragged will (normally) have 
a dynamic boost applied for foreground, and possibly window. 
 This means that that there is not a lot left over for anything else 
on a slow CPU. 
 If priority=absolute, then the thread will not get boosted, but WPS 
*does* have a higher priority (normally) and will tend to be the 
highest priority "ready to run" thread for redraw work. In the case of
a non-PM app, the "repaint" messages are handled by the WPS on behalf 
of the app. If you eliminate the WPS by dragging around a pure PM 
app, there will *still* be lots of repaint messages delivered to the
WPS, so it probably will not help.. 

 You state that you have set all the PMSHELL threads to normal 
priority. I believe you, but I know from past experiences that the WPS
in particular will modify thread priorities as required. I never
bothered to check the code involved to see if it "saved and restored"
previous values, or if it arbitrarily sets them to fixed values. 
 
 I understand the results of the first 3 of the above 4 cases, but the
4th one doesn't fit the facts as I know them (or fit them together). I
wish I could recreate your symptoms and "look under the covers" with a
debug kernel. 

IT>   I would be extremely interested in your educated guess about the
IT>   reason for case 4) above.

 It's the one that bothers me also. Let me know the version and FP 
level of the kernel you are using and I'll see if I can devise a 
customized dynamic trace point that might expose what is happening. 
None of the standard trace points (see the system trace facility) will
give the information we need. 
 Either way, I know there is a lot more than priority adjustment 
involved, if priority adjustment is involved at all (which a custom
set of trace points can prove). 

IT> P.S. I checked out the IBM Developers site. Now there is one cool site!
IT>      I downloaded something called "OS/2 Debugging
Handbook" last night.
IT>      Hope it's the right one... Gonna go read it later tonight, thanks
IT>      for the tip!
   
 All of it? In one night? WOW!! :-)


   Denis       

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

 



--- Maximus/2 3.01