Two little patches (~ one active line apiece). These are relative to
131ac13 btw.
The first addresses some basic responsivity issues, and I think it's
clean and safe:
------------------------------------------------------------
diff -u include/asm-i386/smp.h.orig include/asm-i386/smp.h
--- include/asm-i386/smp.h.orig Mon Nov 9 22:35:24 1998
+++ include/asm-i386/smp.h Thu Dec 17 23:23:44 1998
@@ -235,9 +235,12 @@
* with separate L2 cache it probably depends also on the RSS, and
* for a board with shared L2 cache it ought to decay fast as other
* processes are run.
+ * NJC 17/12/98: If this is equal to DEF_PRIORITY it harms
+ * interactive scheduling, so recommended _maximum_ is 1 less than
+ * DEF_PRIORITY. At the time of writing, DEF_PRIORITY is 20.
*/
-#define PROC_CHANGE_PENALTY 20 /* Schedule penalty */
+#define PROC_CHANGE_PENALTY 15 /* Schedule penalty */
#define SMP_FROM_INT 1
#define SMP_FROM_SYSCALL 2
--------------------------------------------------------
To explain this (to convince me as much as to convince anyone else ;-):
in the case when someone is idly typing characters at the prompt, their
shell process will get added to the run-queue and will *usually* win the
goodness() fight with any hogs that are running. This is because an
idle shell (talking i386 priority/counter numbers now) will have a
counter value of 40 and thus a minimum goodness of 40 assuming it last
ran on the other CPU, and the most a hog can POSSIBLY have is (20+20+1)
(20 for its counter, 20 for the PROC_CHANGE_PENALTY and 1 for being the
current thread). Most of the time (statistically speaking) it'll have
used a couple of jiffies and will thus lose the goodness() race. Thus
the shell will get scheduled, will print the character and then sleep on
read_chan or similar again. (Late addition: I forgot that we now add
priority to the goodness value too, but you get the idea, in the case
that we didn't nice the hogs.)
However, in the odd case when the hog wins the goodness() fight, the
shell ends up waiting for the entire time-slice of the hog. This is my
reasoning. By reducing PROC_CHANGE_PENALTY even by a point or so, we
change this balance, and I've chosen to reduce it by 5 points. (Aside:
20 jiffies equivalent for a processor change seems huge to me). The
patch works, and helps responsiveness of lots of things other than
shells, which are usually idle but (being interactive) want snappy
response when they hit the run-queue. Inasmuch as this patch is small,
it may be preferable to major changes at this late stage.
I'm not at all sure btw, why the effect of the delays seems MUCH worse
than the one-in-ten or so effect you'd expect from looking at the
probability ratios, so I may be missing some subtlety.
==========================
The second patch addresses one specific problem, namely the delays that
happen when you hit "ENTER" in a tcsh on a loaded SMP box. I don't like
this patch at all, it's as ugly as hell, so perhaps it will be obvious
to some guru or other how to fix the underlying problem:
------------------------------------------------------------------
diff -u drivers/char/tty_ioctl.c.orig drivers/char/tty_ioctl.c
--- drivers/char/tty_ioctl.c.orig Thu Dec 17 22:54:50 1998
+++ drivers/char/tty_ioctl.c Thu Dec 17 23:26:02 1998
@@ -52,7 +52,14 @@
if (!tty->driver.chars_in_buffer)
return;
add_wait_queue(&tty->write_wait, &wait);
+#if 0
current->counter = 0; /* make us low-priority */
+ /* NJC 17/12/98: Removed this, as it kills tcsh responsiveness
+ * on SMP machines under load. Removing it is probably the
+ * WRONG thing to do, but the code looks suspect to begin with
+ * so this will do until someone fixes the real problem
+ */
+#endif
if (!timeout)
timeout = MAX_SCHEDULE_TIMEOUT;
do {
------------------------------------------------------------------
The code looks wrong to me anyway: why isn't it possible to do this wait
properly without having to stay on the run-queue and crippling the
process by setting counter to 0? I fully anticipated serious trouble
when I removed this line, but nothing hung. Probably I was just lucky.
Please enlighten me...
Now, I have NO IDEA why the shell (tcsh only, as it issues slightly
different ioctls to bash) hits this issue so hard in SMP but not in UP.
Presumably someone will show me the light on this one... :-)
cheers
Neil
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
