Re: Updated rusage patch

On Fri, 1 Jun 2007, Bruce Evans wrote:

On Fri, 1 Jun 2007, Jeff Roberson wrote:

On Fri, 1 Jun 2007, Bruce Evans wrote:

Well, I think the whole exit/wait path could probably use some attention. There is an incredible amount of locking and unlocking to deal with various races and lock order issues. And there are many subtle effects which aren't immediately obvious. I'm nervous about how many bugs might be caused if we start going down this path so close to 7.0.

I'm afraid to look too closely :-).

Related bugs:
- td_[usip]ticks are still under (j) (sched_lock) in proc.h.
- td_(uu,us}ticks have always (?) been under (k) (thread-local). That
is more correct than (j), but they are updated by an interrupt handler
and seem to be accessed without disabling interrupts elsewhere.
[See other replies for large modifications to this]

Well td_[uisp]ticks are set and cleared while the sched_lock is held. In threadlock.diff the thread lock is responsible for this. That reminds me that I didn't add the per-thread locking to rufetch() in the patch I posted earlier.

But the ticks fields aren't aren't under sched_lock in the patches or
committed version. The could easily be under time_lock, but were
carefully pushed out of that too in the time_lock changes. Per-thread
locking in statclock() and rufetch() could fix this but would give more
locking overhead in statclock().

Please grep for statclock in threadlock.diff. This removes time_lock from statclock all together and protects the whole thing with thread_lock(). With this change all cpus can execute statclock() concurrently with sched_smp.c. This patch also has fixes for locking ruxagg() as well as asserts. It does not yet protect the ru copying in exit(). I want to figure out the synchronization issues with wait first.

Jeff


Bruce

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Updated rusage patch
    ... There is an incredible amount of locking and unlocking to deal with various races and lock order issues. ... That reminds me that I didn't add the per-thread locking to rufetch() in the patch I posted earlier. ...
    (freebsd-arch)
  • Re: + schedule_on_each_cpu-use-preempt_disable.patch added to -mm tree
    ... Because the workqueue code was explicitly switched over to ... per-subsystem cpu-hotplug locking. ... should have one lightweight and scalable primitive that protects ... This problem can be solved using existing locking primitives. ...
    (Linux-Kernel)
  • Re: + schedule_on_each_cpu-use-preempt_disable.patch added to -mm tree
    ... Because the workqueue code was explicitly switched over to ... per-subsystem cpu-hotplug locking. ... should have one lightweight and scalable primitive that protects ...
    (Linux-Kernel)
  • Re: uma_zcreate and number of items to create
    ... because uma probably has some per-zone spinlock, ... the locking in your specific situation (i.e. another lock already ... protects it). ...
    (freebsd-hackers)
  • Re: Updated rusage patch
    ... exit1uses no locking and thus races with statclock. ... statclock() still uses sched_lock but not interrupt atomicity. ... exit1uses no locking and is thus unaffected by sched_lock. ...
    (freebsd-arch)