Date: Mon, 21 Jun 2004 00:44:09 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: calcru: negative time ... followed by freeze Message-ID: <Pine.BSF.4.21.0406210040150.69164-100000@InterJet.elischer.org> In-Reply-To: <20040621132119.Q8596@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Jun 2004, Bruce Evans wrote:
> Ah, here is a likely cause of the bug in -current:
>
> % if (p == curthread->td_proc) {
> % /*
> % * Adjust for the current time slice. This is actually fairly
> % * important since the error here is on the order of a time
> % * quantum, which is much greater than the sampling error.
> % * XXXKSE use a different test due to threads on other
> % * processors also being 'current'.
> % */
> % binuptime(&bt);
> % bintime_sub(&bt, PCPU_PTR(switchtime));
> % bintime_add(&bt, &p->p_runtime);
> % } else
> % bt = p->p_runtime;
>
> The XXXKSE comment is correct that this might be broken. If the (p
> != curthread->td_proc) case happens at all for a running process, then
> it gives a wrong (out of date) timestamp in bt. This wrongness will
> be detected if calcru() is was called called earlier in the current
> timeslice and took the other path here.
It should be fairly easy as there is now a thread state that indicates
that it is actually running now..
>
> The recent change to fill_kinfo() is quite likely to trigger detection
> of this bug. fill_kinfo() is often used to iterate over all processes
> for ps, so it will call calcru() with (p != curthread->td_proc) for
> all processes other than the one running it, and give a bt that is out
> of date for all such processes that are actually running. Since there
> can be at most one running process per CPU, this bug only affects SMP.
>
> The call to calcru() from ttyinfo() may be the only other trigger.
> ttyinfo() picks a process and should rarely or never pick the ithread
> running it, so it will almost always take the (p != curthread->td_proc)
> path. Again, this is only a problem for the SMP case since in the !SMP
> case the picked process must have been switched away from to run the
> ithread, so it cannot be running.
>
> Bruce
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0406210040150.69164-100000>