home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v8 / text0036.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  6.7 KB
  1. From: seismo!munnari!yabbie.rmit.oz!rcodi@sally.utexas.edu (Ian Donaldson)
  2. Date: Tue, 4 Nov 86 09:05:35ligt 
  3.  
  4. > From: pyramid!nsc!hplabs!hpda!hpisoa1!davel (Dave Lennert)
  5. > Date: Wed, 29 Oct 86 10:07:47 -0800
  6.  
  7. I spoke about HUP's sent when an _exit is done, not realising at the time
  8. that it is only done by a sesion-group leader, and only to
  9. the same process-group, obviously (it is now) excluding those
  10. processes running in background.
  11.  
  12. > This key feature is preserved in the POSIX specification.  Perhaps I
  13. > don't understand your statement.
  14.  
  15. I withdraw the statement.
  16.  
  17. In the same article, I wrote: 
  18.  
  19. > > vhangup() will provide clean terminals on a bsd system,
  20. > > and we have improved vhangup further to not just turn off READ/WRITE bits,
  21. > > but to actually redirect the file references to /dev/null (which has
  22. > > the advantage of also dropping DTR reliably). 
  23. > 
  24. > vhangup() is indeed desirable.  It is not required in POSIX because it is 
  25. > not supported on System V and, indeed, breaks System V compatiblity.
  26.  
  27. I forgot to add the other advantage of my vhangup(), in that
  28. any read's by processes from the terminal return EOF rather than
  29. a read-error, and any writes go to the bit-bucket, rather than
  30. producing a write-error.  This is very desirable in stuations where
  31. you have started something in foreground (eg: make, without redirecting I/O) and
  32. you want it to -complete- in background, rather than crash because
  33. it cannot write diagnostics or output...
  34. Of course, you cannot -see- the output, but that is another topic
  35. (along the lines of login-suspension - see ravings in net.unix-wizards
  36. about 6 months ago).
  37.  
  38. Some programs of course would need to be trained to not repeatedly
  39. read beyond EOF assuming somebody is hitting ^D, otherwise they
  40. will do-so forever.  Berkeley 4.2bsd Csh and Mail already have been
  41. trained, and exit if a certain large number of consecutive EOF's are read.
  42. There are probably others.
  43. We have not felt need to modify any more programs, though there is the stray
  44. program that just sits there all day, once a fortnight perhaps.
  45. Readnews seems to be an often offendor (2.10.3).
  46.  
  47. I also wrote:
  48.  
  49. > > Infinite-loop processes don't cause problems with system-response because
  50. > > they are automatically niced (something that is long-needed in UNIX 
  51. > > systems).
  52. > 
  53. > Note that this is NOT desirable on, e.g., realtime systems where that
  54. > long running process may be critical.  I'm also getting tired of having
  55. > my rwhod reniced automatically.
  56. > 
  57. >     Dave Lennert                ucbvax!hpda!davel               [UUCP]
  58.  
  59. Granted, it probably -isn't- desirable at some sites, or perhaps even
  60. some particular users at certain sites, but it is necessary for
  61. any site that has lots of cpu-intensive tasks mixed in with lots
  62. of heavily interactive (eg: vi) sessions.
  63.  
  64. The auto-nicing that I have seen in 4.2 (not sure who added it) whereby
  65. a process gets niced by 1 every 40 cpu seconds until the nice reaches +15
  66. is NOT the sort of thing I am talking about.  The obvious problem with
  67. this algorithm is that it makes no distinctions on what it nices -
  68. it nices compiles (ok, good), but it also nices vi (bad), and eventually
  69. nices the shell (worse, as everything you start inherits the nice
  70. from the shell).  It also makes no distinction on -who- it nices;
  71. except that root is never niced (neither are other users, provided
  72. they are running at elevated priority).  This means that all non-root owned
  73. daemons get niced also.
  74.  
  75. I experimentally implemented a smarter, but still very simple auto-nicing
  76. algorithm that works well here nearly all of the time:  it is an
  77. extension of the one above, except that interactive processes are
  78. identified very simply by the fact that they do tty input (sounds logical).
  79.  
  80. A process is only niced if it consumes N cpu seconds since last doing
  81. some tty input (we have N set small, to 5 cpu seconds). 
  82. This means that an interactive shell is rarely ever
  83. niced, and vi always has a good response time regardless of what
  84. else is going on in the system (unless you're doing complicated
  85. length string searches or the like).  Another "quick hack" allowed
  86. all uid's less-than a certain number (say 2) to be immue to
  87. auto-nicing - this got around the daemon problem, altough very
  88. unelegantly.
  89.  
  90. The kernel mods were trivial, amounting to less than a screenful
  91. of code all-up.  In a nutshell it was one mod to clock.c 
  92. (kern_clock.c for 4bsd), to increment the nice if the conditions
  93. warrant it; and another mod to ttyread() to reset the nice
  94. and the accumulated cpu time since the last ttyread().
  95.  
  96. I have watched people breath discontent over the net with vi's response time, 
  97. and all the hack's that they've tried (including a suid root pre-elevate-nice 
  98. command).  Vi is only mentioned because it is common to almost all
  99. systems.  The problem is much deeper than just vi.
  100.  
  101. Any system that treats non-interactive jobs the same as interactive jobs
  102. is sure to have a rotten response-time.  Interactive jobs are not
  103. jobs that are just "associated" with a terminal either.  People
  104. expecting to do half-hour compiles from the terminal soon learn
  105. that there is no advantage in doing-so, and it is better to come back
  106. later and free up the terminal for somebody else to use (productively).
  107.  
  108. > Note that this is NOT desirable on, e.g., realtime systems where that
  109. > long running process may be critical.  
  110.  
  111. Perhaps, but then my version of auto-nice may solve most of such
  112. problems anyway.  If the program on the real-time system communicates
  113. with other than tty's in an "interactive" fashion, then this could be 
  114. incorporated into the algorithm quite easily.  Lots of things could be 
  115. incorporated into the algorithm - such as a per-user nice-rate and
  116. nice-limit.
  117.  
  118. People will never learn - just telling them to "nice" their jobs
  119. rarely works.  They either forget to, or just don't do it on principle.
  120.  
  121. SVR2 has no way of renicing a job other than restarting it
  122. (counter-productive), and telling somebody to change their nice on the
  123. humungous compile they just started after they've left and gone home is
  124. also often very difficult (read impossible), leaving a very slow
  125. system.
  126.  
  127. Vi and similar programs on our systems nearly always have a
  128. good response time - the times that they don't would most probably
  129. be attributed to excess paging and swapping activity and filesystem I/O.
  130.  
  131. > I'm also getting tired of having
  132. > my rwhod reniced automatically.
  133.  
  134. Maybe it wouldn't be with the algoritm I mentioned (I've never used
  135. rwhod so I can't answer that).
  136.  
  137. At least auto-nicing of some variety I have mentioned should
  138. be provided as a standard -option-.  Those who don't like it
  139. can turn it off, but I'll bet your boots that they will be
  140. in a minority once they've tried it.  Not having the option
  141. at all is not very nice (excuse the pun :-).
  142.  
  143. Ian Donaldson
  144.  
  145. Volume-Number: Volume 8, Number 37
  146.  
  147.