sched_lock && thread_lock()

[Attilio Rao]

Attilio Rao wrote:
> 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.

Ah, and about consistency of functions your previously described, I 
assume nothing vital is linked to it.
vmmeter is just a statistics collector and nothing else, so I don't 
expect nothing critical/vital happens from its fields (I'm sure a lot of 
variables are just bumped up and never decreased, for example). If that 
really happens we should fix that behaviour really, instead than making 
things a lot heavier.

Thanks,
Attilio