From owner-freebsd-current@FreeBSD.ORG Thu Apr 24 04:49:53 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A879937B401; Thu, 24 Apr 2003 04:49:53 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09D5643F3F; Thu, 24 Apr 2003 04:49:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id VAA10910; Thu, 24 Apr 2003 21:49:48 +1000 Date: Thu, 24 Apr 2003 21:49:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: Message-ID: <20030424200754.A24693@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: RE: Renice idle process to -20 causes hang. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 11:49:54 -0000 On Wed, 23 Apr 2003, John Baldwin wrote: > On 23-Apr-2003 Craig Reyenga wrote: > > While running a samba benchmark, I tried 'renice -n -20 10' (pid 10 is idle > > thread) to see what would happen. Turns out that this operation isn't > > illegal, and the system hung accordingly. The benchmark timed out soon > > after, and the console started displaying this message: > > > > swap_pager: indefinite wait buffer: device: ad0s1b, blkno: 776, size: 4096 > > > > over and over, although not rapidly. I'm not sure what to blame; perhaps > > setpriority() should return [EINVAL] or something. I can provide more info, > > upon request. > > Umm, yeah, setpriority should do an EINVAL, but that's not probably the > real bug. idlethreads are never on the run queues, they are truly idle > and only executed when there is nothing else to do. They don't have a > real priority other than "anything else is more important". What might have > happened is that setpiority() put the idle process on the run queue, which > is guaranteed to totally hose your system. There are also idprio threads (which should not be confused with truly idle threads). setpriority seems to change the nice value on all threads except the swapper but this should have no other effect on threads with non-default scheduling classes. The scheduling classes and policies in use are not easy to see. To see some aspects of them, first fix ps so that it doesn't follow a garbage pointer: %%% Index: print.c =================================================================== RCS file: /home/ncvs/src/bin/ps/print.c,v retrieving revision 1.82 diff -u -2 -r1.82 print.c --- print.c 15 Apr 2003 18:49:20 -0000 1.82 +++ print.c 24 Apr 2003 10:53:52 -0000 @@ -641,7 +649,7 @@ char str[8]; unsigned class, level; - + v = ve->var; - lpri = (struct priority *) ((char *)k + v->off); + lpri = &k->ki_p->ki_pri; class = lpri->pri_class; level = lpri->pri_level; %%% This patch also fixes a nearby style bug, but doesn't remove dead code in keywords.c (v->off is correct, but there is no need for it since there is only one priority field to print). Some output from ps with the above patch: % UID PID PPID PRI NI RTPRIO VSZ RSS STAT TT TIME COMMAND % 0 0 0 -16 0 normal 0 12 DLs ?? 0:00.44 swapper % 0 1 0 8 -1 normal 664 236 I