Date: Thu, 27 Apr 2000 22:03:04 -0400 (EDT) From: Luoqi Chen <luoqi@watermarkgroup.com> To: green@FreeBSD.org Cc: hackers@FreeBSD.org Subject: Re: lock-ups due to the scheduler Message-ID: <200004280203.e3S234X10756@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> The deeper problem seems to be that for whatever the process does, it
> never accrues enough estcpu to classify it as hoggy, as a process I
> start with a niceness of -20 cycles through priorities 10 (in the
> very beginning) and 27 at the very highest. This _shouldn't_ be too
> much of a problem, but it never gets to 50 and thus never gets
> rescheduled properly... and this seems to be most of what's causing the
> lockups.
>
Even with max estcpu, the process will have a priority of PUSER - 4, which
puts it at least one run queue higher than all user mode processes, therefore
no user mode processes get a chance to run and the system is locked up.
> > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> > > NICE_WEIGHT * p->p_nice;
> > We should probably offset p->p_nice by PRIO_MIN,
> > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
> > > NICE_WEIGHT * (p->p_nice - PRIO_MIN);
> >
> > To fully utilize the 20 out of 32 run queues for user priorities, we might
> > want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to
> > #define ESTCPULIM(e) \
> > min((e),
> > INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \
> > INVERSE_ESTCPU_WEIGHT - 1)
> > so that a cpu hog at nice 0 would have about the same priority as a low
> > cpu usage nice +20 process.
>
> Yes, this seems right. It seems that the niceness making the priority dip
> below 50 is a bad idea. I think that if we make that modification (which
> is another thing I tried) of niceness values subtracting PRIO_MIN to
> prevent any values less than PUSER, this would fix the bugs we have.
> I missed, when I did it, changing ESTCPULIM, so that probably explains
> why things didn't (I believe) lock up, but (I believe) seemed veerrry
> bad... Also, decreasing NICE_WEIGHT would be a good idea, so I'll try
> all of this out, and report later.
>
Would you try the patch below? I have shown it to Bruce and he approved
it in principle. If it solves your problem, I will probably commit it
sometime tomorrow.
-lq
Index: kern/kern_synch.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.89
diff -u -r1.89 kern_synch.c
--- kern/kern_synch.c 2000/03/28 18:06:42 1.89
+++ kern/kern_synch.c 2000/04/27 20:01:19
@@ -916,7 +916,7 @@
if (p->p_rtprio.type == RTP_PRIO_NORMAL) {
newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
- NICE_WEIGHT * p->p_nice;
+ NICE_WEIGHT * (p->p_nice - PRIO_MIN);
newpriority = min(newpriority, MAXPRI);
p->p_usrpri = newpriority;
}
Index: sys/param.h
===================================================================
RCS file: /home/ncvs/src/sys/sys/param.h,v
retrieving revision 1.63
diff -u -r1.63 param.h
--- sys/param.h 2000/03/27 21:29:33 1.63
+++ sys/param.h 2000/04/27 19:19:59
@@ -111,7 +111,7 @@
#define PCONFIG 32
#define PLOCK 36
#define PPAUSE 40
-#define PUSER 50
+#define PUSER 46
#define MAXPRI 127 /* Priorities range from 0 through MAXPRI. */
#define PRIMASK 0x0ff
Index: sys/proc.h
===================================================================
RCS file: /home/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.102
diff -u -r1.102 proc.h
--- sys/proc.h 2000/04/16 18:53:29 1.102
+++ sys/proc.h 2000/04/27 14:33:23
@@ -405,10 +405,10 @@
* the range 100-256 Hz (approximately).
*/
#define ESTCPULIM(e) \
- min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_MAX - PPQ) + \
+ min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN)) + \
INVERSE_ESTCPU_WEIGHT - 1)
#define INVERSE_ESTCPU_WEIGHT 8 /* 1 / (priorities per estcpu level) */
-#define NICE_WEIGHT 2 /* priorities per nice level */
+#define NICE_WEIGHT 1 /* priorities per nice level */
#define PPQ (128 / NQS) /* priorities per queue */
extern u_long ps_arg_cache_limit;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004280203.e3S234X10756>