Date: Sun, 16 May 2004 19:46:37 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org> Subject: Re: exit1()/scheduler question.. possible typo? Message-ID: <20040516190430.O798@gamplex.bde.org> In-Reply-To: <20040510162831.X1105@gamplex.bde.org> References: <Pine.BSF.4.21.0405091556030.24403-100000@InterJet.elischer.org> <20040510162831.X1105@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 May 2004, Bruce Evans wrote: > On Sun, 9 May 2004, Julian Elischer wrote: > > > in exit1 there is an assertion to test that the exiting process > > is not init. (proc 1 by tradition..) > > > > yes later, nearly at the end we see: > > > > /* > > * Allow the scheduler to adjust the priority of the > > * parent when a kseg is exiting. > > */ > > if (p->p_pid != 1) > > sched_exit(p->p_pptr, td); > > > > > > firstly, the comment is wrong but, the question comes.. > > "if init can not get here then why have the test?" > > ... > > I get the impression that possibly this should be p->p_pptr->p_ppid > p_pid > > but I don't know enough about ULE to know if that makes sense. > > > > (maybe it should be (p->p_pptr != initproc) > > My version already used initproc here and elsewhere, but was missing the > fix for the LHS. I tried using (p->p_pptr != initproc), but this broke load averages and thus caused problems like sendmail refusing to run. We were depending on the bug to get sched_exit() called unconditionally. The call must now always be made, because one of the things that sched_exit() does for the 4BSD scheduler is decrement the load average counter. The nearby call to cpu_sched_exit() is also bogus: % cpu_sched_exit(td); /* XXXKSE check if this should be in thread_exit */ % /* % * Allow the scheduler to adjust the priority of the % * parent when a kseg is exiting. % */ % if (p->p_pid != 1) % sched_exit(p->p_pptr, p); Scheduling is not cpu-specific, and if it were then it should be done by sched_exit() calling cpu_sched_exit(). In practice, cpu_sched_exit() is null for all arches except sparc64. For sparc64, it does things related to exiting but unrelated to scheduling. ISTR you asking about sparc64's cpu_sched_exit() separately. On i386's, things related to exiting are done in cpu_exit() and cpu_thread_exit(). This seem to be the right places to do such things. However, things are misplaced internally there. The debugger registers are per-thread, so they should only be reset in cpu_thread_exit(). The first senetence of the nearby comment on the call to thread_exit() is also bogus: % /* % * Make sure the scheduler takes this thread out of its tables etc. % * This will also release this thread's reference to the ucred. % * Other thread parts to release include pcb bits and such. % */ % thread_exit(); This call to thread_exit() doesn't do anything related to scheduling, since p->p_numthreads is 1. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040516190430.O798>