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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"