home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / aix / 12502 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  1.9 KB
  1. Path: sparky!uunet!vtserf!black-ice.cc.vt.edu!valdis
  2. From: valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
  3. Newsgroups: comp.unix.aix
  4. Subject: Re: AIX 3.2.3 on RS/6000-560 - strange scheduler behavior
  5. Message-ID: <10384@vtserf.cc.vt.edu>
  6. Date: 11 Dec 92 21:06:48 GMT
  7. References: <10325@vtserf.cc.vt.edu> <Bz3v18.12Eu@austin.ibm.com>
  8. Sender: news@vtserf.cc.vt.edu
  9. Organization: Virginia Tech, Blacksburg, VA
  10. Lines: 30
  11.  
  12. In article <Bz3v18.12Eu@austin.ibm.com> chukran@austin.vnet.ibm.com(Rudy Chukran) writes:
  13. >Your only option is to play with schedtune.  If you try to raise the
  14. >priority of "favored processes", what will likely happen is that they
  15. >will get suspended sooner.
  16.  
  17. After some playing with schedtune and the various knobs, it looks like
  18. '-m 15' is the flag that I needed - the system is now running 20 copies
  19. of the thrasher program, and paging at about 50/sec, but character echo
  20. is stable at very fast, and trivial things like 'ls' are now down into
  21. the 1-5 second wait time.
  22.  
  23. The problem was apparently the system falling into a pathological
  24. endpoint on the algorithms.  With 512M of memory, it was possible for
  25. 12 or 14 copies of the program to be fully resident.  So the *other*
  26. 5 would cause the system to thrash, and the default "-m 2" value
  27. would cause essentiall the world to become suspended.  As things
  28. came off the suspend list, they'd drive the memory overcommit back
  29. up, and everything went back into suspension.  So the end result
  30. was that at any given time, all 2 of the processes that weren't suspended
  31. were number crunchers, and interactive shells were *all* suspended.
  32.  
  33. >If that doesnt work, then turn off loadcontrol again, and start messing
  34. >with priorities.  Try kicking up the priorites of the favored processes
  35. >with either nice or setpri. You will have to be root to increase
  36. >priorities in this manner.
  37.  
  38. Fortunately, I get to avoid doing that...  Would have been a pain to
  39. try to enforce a "all login shells have a higher priority"..
  40.  
  41. /Valdis
  42.