Re: sched_lock && thread_lock()

Jeff Roberson wrote:

On Mon, 21 May 2007, Bruce Evans wrote:

On Sun, 20 May 2007, Jeff Roberson wrote:

Attilio and I have been working on addressing the increasing problem of sched_lock contention on -CURRENT. Attilio has been addressing the parts of the kernel which do not need to fall under the scheduler lock and moving them into seperate locks. For example, the ldt/gdt lock and clock lock which were committed earlier. Also, using atomics for the vmcnt structure.

Using atomics in the vmmeter struct is mostly just a pessimization and
and obfuscation, since locks are still needed for accesses to more
than one variable at a time. For these cases, locks are needed for

You are right, there are some cases which this pessimized. I wanted to make sure the cnt members that previously were protected by the sched_lock were still correct. However, I overlooked some of these which were accessed many at a time. What should happen is we should find out if any locks do protect the remaining members and if so, don't use VMCNT*, but mark the header describing how they are protected.

Sorry, but I strongly disagree.
You have to keep in mind some tips here:
1) reads don't pay penalties and at 99% of times multiple accesses you describe are reads or mostly 1 write + several reads
2) If you want to use a spinlock (or a sleepable lock) for doing a write or a read you have, in the better case, 2 atomics ops and 1 normal op (the read or the write in question). So, without caring about the problem you will increase latency for all reads too (that the current patch doesn't do), you have a lot more overhead even in the case of writes too.
3) If you use a lock, you need always to use it, you cannot do that only for some paths.

The choosen approach is certainly the faster for mantaining a consistent
approach of all vmmeter fields.

Attilio

_______________________________________________
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