Kernel monitor, the return

John Baldwin jhb at FreeBSD.org
Wed Feb 23 11:04:43 PST 2005


On Wednesday 23 February 2005 09:00 am, Andrey Simonenko wrote:
> On Tue, Feb 22, 2005 at 03:34:41PM -0500, John Baldwin wrote:
> > You don't need sched_lock to check PS_INMEM, proc lock is sufficient
> > (PS_INMEM is magic this way).
>
> I suggested the author of the original letter to get lock on sched_lock,
> because statclock() modifies ru_idrss and ru_isrss values and that
> values are read in that kproc.  Having read some code in the kernel,
> now I think that lock on sched_lock is needed only before reading
> ru_idrss and ru_isrss for current thread.  Am I right?  (at least
> getrusage() does in this way.)
>
> In private letters we found that it is better to use _PHOLD/_PRELE
> for that task.

Well, the proc lock protects the p_stats pointer.  There isn't a lock 
protecting the reading of the ru_* variables because getting the lock 
wouldn't actually buy you anything.  It's a race that it doesn't hurt to 
lose.  _PHOLD() can be very expensive on 5.x as if the process is swapped out 
it is going to block until the process is swapped back in.  Just locking proc 
lock and skipping if PS_INMEM is clear is going to be a lot quicker.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-hackers mailing list