On Tuesday, 1 December 1998,
     DENIS TONN wrote to IVAN TODOROSKI about 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

  Only the second copy. And what's surprising is that it DOES make a
  difference. If I drag folders around with PMSHELL's (second instance)
  default priorities, apps freeze in the background (using the flat
  kernel), but if I reset its priorities then the freezing goes away
  when I drag folders or other windows that PMSHELL owns around. Hope
  this provides a clue for you.

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

  Hope this provides some clues for you, as I'm running out of ideas.

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

  (I promissed to do this a while ago, but I got entangled in some
  really messy OREXX programming lately, and never got around to
  actually doing it... sorry)

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!

 DT>  I think if we look at what happens when you drag a window around, it
 DT> might help. I don't think it will explain everything, but some of it.

  Well I made a program that prints its priority about 10 times a
  second, and decreases its priority about once in 3 seconds (it starts
  from TC, delta 31)

  With the default kernel, regardless of the PRIORITY setting, the
  program just freezes as soon as it drops below TC, delta 0. There is
  no level where it just slows down a little, the drop is very sharp.
  One moment it runs full speed, and the next it totally freezes. This
  would suggest that the priority of the drawing is somewhere between
  TC-0 and Server-31.

  With the flat kernel, PRIORITY=DYNAMIC (the dreaded case 4), the
  drop-off point is Regular, delta 1. As soon as it drops below delta 1,
  and while is stays on delta 0, it slows down somewhat because of the
  dragging, but DOESN'T FREEZE, and when it drops below Reg-0, to
  Idle-31 and below, it freezes (but at Idle priority it IS SUPPOSED to
  freeze). This would suggest that the priority of PM drawing in this
  case is exacly equal to Reg-0, since at that priority both the drawing
  and the background program visibly slow down, which means that both of
  the threads are executed in a round-robin fashion. This happens only
  at equal priorities, as you've already explained.

  Anyway, this "conclusions" of mine are nothing more than wild guesses
  based on limited understanding. The facts are real however, and I
  present them here in hope that you'll be able to extract some more
  useful clues and conclusions from them.

  Thank you for your interest and time! I really appreciate it.

 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.

  I'm currently trying to talk a friend of mine into giving me a 386 he
  doesn't use anymore and which just gathers dust on his attic, so
  maybe I'll just try installing OS/2 on that piece of junk! :)

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

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

   I'll try to eliminate only these two boosts from the table (instead
   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.

  I check the priorities before and AFTER the experiments, and they do
  not change. But if I work on my computer for some time, they do tend
  to regain their original priority distribution. But during the
  experiments, the priorities are more or less in the regular class,
  delta 0.

 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.

    And I wish I had a debug kernel, a kernel debugger, and basic
    knowledge of how to operate it... :(

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

  I'm using Warp 4 GA, and the kernel has this string inside:

    Internal revision 9.023, 95/11/07

 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.

    System trace facility?!??!?????? Now HOW did I manage to miss that
    one?! :(  Thanks for the tip, I'll try to look into it immediately.
    Even if it doesn't help directly, atleast I'll learn something more
    about OS/2 with it (atleast I hope so).

 DT>  Either way, I know there is a lot more than priority adjustment
 DT> involved, if priority adjustment is involved at all (which a custom
 DT> set of trace points can prove).

   Yeah?! Great! I'll help you in any way I can and know!

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!
 DT>
 DT>  All of it? In one night? WOW!! :-)

   Yeah, I wish! :(

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

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

                                                            - Ivan -

.!. "The Sex Mad Russian"                   By Ivantor Titsoff
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ