sched_lock && thread_lock()
Jeff Roberson
jroberson at chesapeake.net
Mon May 21 09:32:00 UTC 2007
On Mon, 21 May 2007, Attilio Rao wrote:
> 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.
Well, Attilio is right that in most cases using a lock to save a few
atomics is going to be more expensive. There is also the procedural cost
of the lock and the cache miss etc. However, in some cases there is
already a lock available that is protecting the counter.
Furthermore, there are a few cases, most notably paging targets, where
code depends on the value of the counters. For most fields, I believe we
have a good approach, however, there are a few that could be minorly
improved. The question is whether it's worth inconsistently accessing the
counters to save a few atomics which likely have an immeasurable
performance impact.
Thanks,
Jeff
>
> Thanks,
> Attilio
>
More information about the freebsd-arch
mailing list