sched_lock && thread_lock()

[Attilio Rao]

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