On Saturday, 5 December 1998,
     DENIS TONN wrote to IVAN TODOROSKI about Poking inside the kernel

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.

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

 OK, so we're narrowing the choice. When I read this, I thought "Whew...
 finally!".

  But (always that but) the little worm deep in my brain still wasn't
  satisfied and kept chewing untill I agreed to do some more
  experiments. This time, I decided to completely disable the WPS, by
  puting SET RUNWORKPLACE=C:\OS2\CMD.EXE in CONFIG.SYS. So, the WPS is
  gone during my next experiments.

  Just look at what happens when I do "dir os2krnl*" on my boot drive:

 Volume in drive C is OS2            Serial number is A72B:F015
  Directory of  C:\os2krnl*

12-08-98   8:15         780,170           0  OS2KRNL
11-23-98  19:30         780,170           0  OS2KRNL.flat
11-20-98  12:00         586,875           0  OS2KRNL.modified_GA_for_VDM
12-08-98   7:50         780,170           0  OS2KRNL.noFG
12-08-98   8:16         780,170           0  OS2KRNL.noFG_noWB
11-23-98  19:31         780,170           0  OS2KRNL.normal
12-08-98   8:00         780,170           0  OS2KRNL.noWB
 9-05-98   4:39         586,875           0  OS2KRNL.original_GA_kernel
       5,854,770 bytes in 8 files and 0 dirs    5,856,256 bytes
       allocated
            15,935,488 bytes free

  :))) I have 6 megs worth of kernels!


So here's a short summary of what happened. I restored the default
kernel, and rebooted.

So I'm having only three CMD windows open, and dragging any of them
freezes the others (except for the starvation boost). The problem is
present even with the WPS gone. :(

I then edited the default kernel and removed ONLY the foreground boost
from it.
Reboot.

Three CMD windows are opened, and nothing else (WPS is down). To verify
that the FG Boost is really gone, I do dir /s in two of them, and when
switching from one to the other, there is no noticeable difference
between them. So far, so good. Then I start dragging the third window
with nothing running in it, and both background windows promptly grind
to a halt :(( So, it isn't the FG Boost.

Next on the list is the Window Boost. Restoring default kernel, removing
ONLY Window Boost from it.
Reboot.

Again three CMD windows, no WPS. Running dir /s in two of them to see
what's the status of the FG Boost, and it is there all right. But will
they freeze when I drag the third window around (the third window will
have the foreground boost all for itself)?

  THE ANSWER IS: NO! :)

  So, the window boost ALONE is responsible for all this!

 I later eliminated the FG Boost too, since I never did like it, and it
 was giving me quite a headache when some stupid keyboard-polling DOS
 app was in the foreground, doing nothing, and yet sucking up all the
 cycles, and unneccesarilly slowing down my background apps.

 So I'm now running without the foreground and the window boost, and
 things run JUST FINE!

  So, the problem wasn't in the WPS (although it was making it worse by
  the higher-than-default priorities of most if its threads). It wasn't
  in the PM either, it was just in the priority table, specifically in
  the Window Boost...



  And one more thing surfaced. It seems that the window boost (or
  something simmilar) is still somehow present when PRIORITY=ABSOLUTE.

   Why is this?

  Well I also tried this combination:

   Kernel: default
   PRIORITY=ABSOLUTE
   SET RUNWORKPLACE=C:\OS2\CMD.EXE

  and I had only CMD windows open, all running at Regular-0. When I
  dragged any one of them, the others froze... cannot explain this one.

   The starvation and the foreground boost were gone tho, I checked
   that. So PRIORITY=ABSOLUTE doesn't eliminate *all* the boosts, only
   some.


 DT> 0062  001f 0015 001f 000d blk 021f 9ba4a000 9bcc1bb0 9bc75020 0eac 12
 DT> PMSHL32
 DT> 0068  001f 0015 001f 0010 blk 0200 9ba50000 9bcc1bb0 9bc75c20 0ed4 12
 DT> PMSHL32

 DT> The priority listed above is the "internal" priority. What is
 DT> happening is that the dragging is uncovering various portions of
 DT> the windows of the "user interface" and *IT* is driving lots of
 DT> redraw requests, on high priority threads.

  Yes, I'm aware of that now thanks to you, but it was only part of the
  problem, it was only emphasizing it. The freezing happened even when I
  completely removed the WPS and ran only CMD windows at default
  priority. But eliminating the Window Boost from the priority table
  pretty much solved everything!

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.
 DT>
 DT> Is this with the priorities of the user interface copy of pmshell
 DT> set to normal? (I forget).

     Yes.


IT>>   In my experience, severely constrained systems are probably the BEST
IT>>   and fastest way to flush out hidden defficiencies and performance
IT>>   bottlenecks.

 DT> True, but at the same time you should stay within recommendations.
 DT> Like not turning on full screen dragging on slow processors. The
 DT> design and tuning factors are based on certain assumptions. When
 DT> you move outside the range of these assumptions you tend to get
 DT> misleading results. Full screen dragging will cause a lot more

   Quite right, that Window Boost and Full Screen dragging were
   certainly meant for faster machines, but thanks to the information
   you so kindly provided, I managed to make it work to my satisfaction
   on my machine too! Thanks!

  I plan to stick with this last kernel modification (all the boosts
  present EXCEPT foreground and window boost)

  DT>>  Throw in the fact that the window being dragged will (normally) have
  DT>> a dynamic boost applied for foreground, and possibly window.

   Well you're right on the spot here! Strangely enough, the foreground
   boost didn't have any influence on window dragging, but that window
   boost sure did!

    The next thing I'm gonna try is to follow your suggestions and try to
    learn a little about the tracing utilities, and see if I can extract
    something inteligible from them.


                                                            - Ivan -

.!. "I'd love to help you out. Which way did you come in?" - Groucho Marx
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ