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

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

 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.
 
  DT>  Both copies of PMShell? If not, which one? Keep in mind that
  DT> "PMSHELL.EXE" is really just a "driver" for a
bunch of functions in
 
IT>   Only the second copy. And what's surprising is that it DOES make a
IT>   difference. If I drag folders around with PMSHELL's (second instance)
IT>   default priorities, apps freeze in the background (using the flat
IT>   kernel), but if I reset its priorities then the freezing goes away
IT>   when I drag folders or other windows that PMSHELL owns around. Hope
IT>   this provides a clue for you.

 Yep.. This means that it is the WPS that is doing the "interfering" 
that you are seeing, not PM. 

IT>   If I drag non-WPS windows (with no open folders on the desktop, so
IT>   they wouldn't get repaint messages when I drag over them), the
IT>   freezing doesn't occur, regardless of PMSHELL's priorities (again
IT>   using the flat kernel - I use that one as the default kernel now). The
IT>   non-WPS application that owns the window is set to Regular-0.
IT> 
IT>   Hope this provides some clues for you, as I'm running out of ideas.

 Yep.. You are being mislead by the fact that there are 2 copies of 
"PMSHELL" running, each with quite different responsibilities. The 
first copy is the base PM functions, including message delivery and 
drawing support. The second copy is the the user interface only. It 
"uses" the functions of the first copy, just as any other PM app would
do. PMSHELL.EXE is simply a "driver" for a bunch of DLL's. The DLL's
involved are quite different depending on which copy you are looking 
at. 
 You can replace the user interface quite easily, and still maintain 
PM support. The RUNWORKPLACE statement in config.sys controls this. 
See alternative packages that replace this for examples of usage 
(MSHELL, Process Commander, etc). 

IT>   I will try to eliminate boosts one by one selectively from the default
IT>   kernel (instead of all of them like it is now) to see exactly which
IT>   boost(s) (if any) are responsible for that freezing... maybe that will
IT>   provide additional clues as to what is going on.

 [..]

IT>   Well I made a program that prints its priority about 10 times a
IT>   second, and decreases its priority about once in 3 seconds (it starts
IT>   from TC, delta 31)
IT> 
IT>   With the default kernel, regardless of the PRIORITY setting, the
IT>   program just freezes as soon as it drops below TC, delta 0. There is
IT>   no level where it just slows down a little, the drop is very sharp.
IT>   One moment it runs full speed, and the next it totally freezes. This
IT>   would suggest that the priority of the drawing is somewhere between
IT>   TC-0 and Server-31.

 The user interface (second copy of PMshell) has LOTS of threads with 
TC Priority: 

Slot  Pid  Ppid Csid Ord  Sta Pri  pTSD     pPTDA    pTCB     Disp SG Name
0042  001f 0015 001f 0001 blk 0500 9ba2a000 9bcc1bb0 9bc71020 0ed4 12 PMSHL32 
0044  001f 0015 001f 0002 blk 0800 9ba2c000 9bcc1bb0 9bc71420 0ee0 12 PMSHL32 
0045  001f 0015 001f 0003 blk 080a 9ba2d000 9bcc1bb0 9bc71620      12 PMSHL32 
0046  001f 0015 001f 0004 blk 0800 9ba2e000 9bcc1bb0 9bc71820 0ed4 12 PMSHL32 
0047  001f 0015 001f 0005 blk 0800 9ba2f000 9bcc1bb0 9bc71a20      12 PMSHL32 
0048  001f 0015 001f 0006 blk 0800 9ba30000 9bcc1bb0 9bc71c20 0f00 12 PMSHL32 
0049  001f 0015 001f 0007 blk 0200 9ba31000 9bcc1bb0 9bc71e20 0ee0 12 PMSHL32 
0054  001f 0015 001f 0008 blk 0200 9ba3c000 9bcc1bb0 9bc73420 0ed4 12 PMSHL32 
005d  001f 0015 001f 0009 blk 0500 9ba45000 9bcc1bb0 9bc74620      12 PMSHL32 
005e  001f 0015 001f 000a blk 0200 9ba46000 9bcc1bb0 9bc74820      12 PMSHL32 
0067  001f 0015 001f 000b blk 0800 9ba4f000 9bcc1bb0 9bc75a20      12 PMSHL32 
0061  001f 0015 001f 000c blk 0500 9ba49000 9bcc1bb0 9bc74e20 0eb8 12 PMSHL32 
0062  001f 0015 001f 000d blk 021f 9ba4a000 9bcc1bb0 9bc75020 0eac 12 PMSHL32 
0068  001f 0015 001f 0010 blk 0200 9ba50000 9bcc1bb0 9bc75c20 0ed4 12 PMSHL32 

 The priority listed above is the "internal" priority. What is happening is
that the dragging is uncovering various portions of the windows of the 
"user interface" and *IT* is driving lots of redraw requests, on high 
priority threads. 
 
IT>   With the flat kernel, PRIORITY=DYNAMIC (the dreaded case 4), the
IT>   drop-off point is Regular, delta 1. As soon as it drops below delta 1,
IT>   and while is stays on delta 0, it slows down somewhat because of the
IT>   dragging, but DOESN'T FREEZE, and when it drops below Reg-0, to
IT>   Idle-31 and below, it freezes (but at Idle priority it IS SUPPOSED to
IT>   freeze). This would suggest that the priority of PM drawing in this
IT>   case is exacly equal to Reg-0, since at that priority both the drawing
IT>   and the background program visibly slow down, which means that both of
IT>   the threads are executed in a round-robin fashion. This happens only
IT>   at equal priorities, as you've already explained.
 
 Is this with the priorities of the user interface copy of pmshell set to 
normal? (I forget). 


  DT> It is hard for me to independently verify (or recreate for analysis)
  DT> your results, or to design and test an "experiment" here to
  DT> demonstrate. I don't have a slow enough system to exhibit the
  DT> symptoms as your does.
 
IT>   I'm currently trying to talk a friend of mine into giving me a 386 he
IT>   doesn't use anymore and which just gathers dust on his attic, so
IT>   maybe I'll just try installing OS/2 on that piece of junk! :)
IT> 
IT>   In my experience, severely constrained systems are probably the BEST
IT>   and fastest way to flush out hidden defficiencies and performance
IT>   bottlenecks.

 True, but at the same time you should stay within recommendations. Like 
not turning on full screen dragging on slow processors. The design and 
tuning factors are based on certain assumptions. When you move outside the 
range of these assumptions you tend to get misleading results. Full screen 
dragging will cause a lot more drawing requests to be sent to the 
underlying PM functions. The priority of the drawing threads for each of 
the PM apps becomes a very strong factor here - the WPS (second copy of 
pmshell) will be one of the prime factors here. 

  DT>  Throw in the fact that the window being dragged will (normally) have
  DT> a dynamic boost applied for foreground, and possibly window.
 
IT>    I'll try to eliminate only these two boosts from the table (instead
IT>    of all of them), to see if it will make a difference.

  DT>  You state that you have set all the PMSHELL threads to normal
  DT> priority. I believe you, but I know from past experiences that the WPS
  DT> in particular will modify thread priorities as required. I never
  DT> bothered to check the code involved to see if it "saved and
restored"
  DT> previous values, or if it arbitrarily sets them to fixed values.
 
IT>   I check the priorities before and AFTER the experiments, and they do
IT>   not change. But if I work on my computer for some time, they do tend
IT>   to regain their original priority distribution. But during the
IT>   experiments, the priorities are more or less in the regular class,
IT>   delta 0.

 Checking "before and after" the experiment is not suffcient. The fact that
the threads DO recover their priorities tells me that they are manually 
manipulating their priorities dynamicly (outside of dynamic boost factors).
It could easly be that they are "querying" their priority, setting 
themselves high, doing the draw api call then restoring their priority 
immediately. This would not be visable with a "before and after" look, but 
could easily explain some of the results you are seeing.. It is not a staic
model. This is why we need the trace facilty. 
 Set yourself a trace buffer (TRACEBUF=63 in config.sys) and try turning on 
traces with the TRACE ON KERNEL(TK) command before your tests. Extract and 
format the trace buffer with TRACEFMT. 
 Note: due to a bug in Warp 4 GA, you need to issue the TRACE ON command 
with your default drive as the boot drive (it looks for \OS2\SYSTEM\TRACE
directory without appending a drive letter). 

  DT>  I understand the results of the first 3 of the above 4 cases, but the
  DT> 4th one doesn't fit the facts as I know them (or fit them together). I
  DT> wish I could recreate your symptoms and "look under the
covers" with a
  DT> debug kernel.
 
IT>     And I wish I had a debug kernel, a kernel debugger, and basic
IT>     knowledge of how to operate it... :(

 If you installed Warp 4 with the Servicability and Diagnostic aids, you 
already have a dump formatter available. See the help under TRADUMP on how 
to set up a dediicated partition to dump to, and the Warp debug handbook 
should give you a start into dump analysis. The difference between a dump 
and debug kernel is that a dump is a "static" picture of the system at the 
time of the dump vs a "live" system. You can also analyze a dump on the 
same machine that took it, you need a second machine to do "live" 
debugging with the debug kernel.  

 IT>>   I would be extremely interested in your educated guess about the
 IT>>   reason for case 4) above.
 
  DT>  It's the one that bothers me also. Let me know the version and FP
  DT> level of the kernel you are using and I'll see if I can devise a
 
IT>   I'm using Warp 4 GA, and the kernel has this string inside:
IT> 
IT>     Internal revision 9.023, 95/11/07

 Thanks.. I am on "semi-vacation" from now until the new year. Maybe I'll 
get a chance to build a set of custom trace points that will expose the
reasons for this. 

  DT> customized dynamic trace point that might expose what is happening.
  DT> None of the standard trace points (see the system trace facility) will
  DT> give the information we need.
 
IT>     System trace facility?!??!?????? Now HOW did I manage to miss that
IT>     one?! :(  Thanks for the tip, I'll try to look into it immediately.
IT>     Even if it doesn't help directly, atleast I'll learn something more
IT>     about OS/2 with it (atleast I hope so).

  Yep.. There is a LOT you can do with the standard trace points and 
trace facility. See HELP TRACE and the Troubleshooting folder INF file 
covering trace. There is also a lot of information in the debug handbook on
trace, including how to build trace points for your own applications (or 
other applications). There is even more you can do with the trace facility 
by building "custom" trace points using the dtrace facility (also shipped 
with Warp 4). 

 IT>>      I downloaded something called "OS/2 Debugging
Handbook" last night.

IT>    I also downloaded the entire Control Program and PM references, and
IT>    also the TCP/IP programming reference. And I'm reading them all at
IT>    once, sort of in parallel! I guess the priority table in my brain
IT>    flattened too... :)

IT>    My mind is completelly and utterly boggled, but I'm slowly beggining
IT>    to sort things out. I hope that in about two weeks time I'll have
IT>    more or less thorough basic understanding of what the hell is
IT>    actually going on inside that machine of mine... Thanks for pointing
IT>    me in the right direction.

 I fully expect that it will take a while for the relationships and 
ramifications to sink in. 


   Denis       

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

 




--- Maximus/2 3.01