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

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

IT>   YESSS!!! Thanks man! By poking that priority table inside the kernel I
IT>   finaly managed to change the priorities of PM drawing, and now my
IT>   applications don't freeze when I drag windows around! Cool...
IT> 
IT>   But, by doing that, I also lost some things. :(
IT> 
IT>   So, to make a long story short, I'll just sumarize the result of my
IT>   experiments, and try to draw some conclusions...
IT> 
IT> 1)
IT>   PRIORITY=ABSOLUTE
IT>   PMSHELL thread priorities: default
IT>   OS/2 kernel: unmodified
IT> 
IT>   Dragging windows around freezes other applications. It seems there is
IT>   a boost applied, even though priority is set to ABSOLUTE.

 I doubt it. I suspect what you are seeing here is related to the 
non-preemtable portions of the driver. 
 I have looked at the internal priorities when PRIORITY=ABSOLUTE, and
they never change except under application control. The scheduler will
do a pure "look for the highest priority, ready to run" thread, an 
dispatch it. 
 Keep in mind that the PM "drawing thread" will be involved here, and 
it may have a higher priority. 

IT> 2)
IT>   PRIORITY=DYNAMIC
IT>   PMSHELL thread priorities: default
IT>   OS/2 kernel: unmodified
IT> 
IT>   Same as the above.

 And I would expect to see such. .

IT> 3) (Now this is interesting)
IT>  PRIORITY=DYNAMIC
IT>  PMSHELL thread priorities: default
IT>  OS/2 kernel: *modified*
IT> 
IT>   The kernel modification is the simplest one I could think of.
IT>   I changed the priority table to look like this:
IT> 
IT> +----------------------------------------------------------------------+
IT> |Starved         08 --------------------------------------------------+|
IT> |Device I/O      10 -------------------------------------------------+||
IT> |Foreground      20 ------------------------------------------------+|||
IT> |Window          40 -----------------------------------------------+||||
IT> |VDM Interrupt   80 ----------------------------------------------+|||||
IT> |============================================================     ||||||
IT> |Not Keyboard (04)             | Keyboard (04)                    ||||||
IT> |Server  Idle    Regular TC    | Server  Idle    Regular TC       IWFDS|
IT> |0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// -----|
IT> |0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// ----S|
IT> |0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// ---D-|
IT> |0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// ---DS|
IT> |0x300,  0x100,  0x200,  0x800,| 0x300,  0x100,  0x200,  0x800,// --F--|
IT> 
IT>    ..... etc.
IT> 
IT>  IOW, I made every row in the table exactly the same as the first, thus
IT>  eliminating EVERY priority boost. You may think that this is the same
IT>  as PRIORITY=ABSOLUTE (I did at first), but it is not so.

 No, there are other boosts applied outside of this table. VDM 
similated interrupts and (possibly) voluntary yield boosts are 
examples of this. 

IT>   When I drag application windows around (not WPS windows like folders,
IT>   properties notebooks etc), other applications don't freeze anymore,
IT>   but simply slow down, which is the behavior I expect. So far so
IT>   good...
IT> 
IT>   But when I tried to drag WPS windows, even small folders, applications
IT>   froze again... :(
IT> 
IT>   Application windows didn't manifest this type of behaviour, and the
IT>   applications to which they belonged had Regular, delta 0 priorities.
IT>   It was obvious that no boosts are being applied, so I concluded that
IT>   the reason for this is within PMSHELL.EXE. Many of its threads run at
IT>   Server and TimeCritical priority.

 Yep.. 

IT> PMSHELL thread priorities: changed to regular, delta 0
IT> 
IT>   I changed the priority of all the threads in PMSHELL.EXE (second
IT>   instance) to Regular, delta 0 (thread #2 could not be changed,
IT>   because it was constantly reseting its priority to Time Critical,
IT>   delta 31). And that finaly did it!
IT> 
IT>   Now everything works OK. Application don't stop when I drag windows
IT>   around, although they slow down noriceably (but this is to be
IT>   expected)!
IT> 
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.

 No, the PM drawing threads do NOT get "boosted". They may be setting 
themselves to a higher level (temporarily) or passing off the work to
high priority threads (more likely), but they are NOT boosted with 
PRIORITY=ABSOLUTE. 

IT>   One can argue that this is because the window you're dragging is in
IT>   the foreground, and that it is actually the foreground boost that is
IT>   causing this, but at PRIORITY=ABSOLUTE there is no foreground boost,
IT>   and yet applications freeze when a window is dragged.
IT> 
IT>   I guess that this misterous boost may be that "window boost" you
IT>   described... I'll try to devise a pattern of modifying the priority
IT>   table in such a way that will eliminate ONLY the window boost, and
IT>   leave all other boosts intact, and see if this will have any effect.

 Your experiments in this area are doing more to expose the behaviour 
of PM and the graphics driver than they are in exposing the behaviour 
of priority adjustment. Keep this FIRMLY in mind with the above "test 
scenerio". 
 If you wish to actually play with testing the priority boosting of 
the kernel, you need to eliminate these variables from your 
experiments. 



   Denis       

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

 



--- Maximus/2 3.01