Re: sched_lock && thread_lock()

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
correctness, and are also probably more efficient if there are > 2
accesses. Then lock poisoning requires the same locks to be held for
updates of the variables (to prevent variables changing while you are
using them), and atomic updates of single variables are a pessimization
too. The VMCNT*() ineterface encorages this pessimization and has other
problems (messes with volatile, and not actually doing atomic accesses
for VMCNT_GET()). Some of the cases where locks aren't needed (mainly
for userland-only statistics) were already handled better by
PCPU_LAZY_INC(). Unfortunately, the method used in PCPU_LAZY_INC()
doesn't work for variables that the kernel wants to access as globals.

Example of code with multiple accesses:

% /*
% * Return the number of pages we need to free-up or cache
% * A positive number indicates that we do not have enough free pages.
% */
% % static __inline % int
% vm_paging_target(void)
% {
% return (
% (VMCNT_GET(free_target) + VMCNT_GET(cache_min)) - % (VMCNT_GET(free_count) + VMCNT_GET(cache_count))
% );
% }

Without holding a lock throughout this, this returns a garbage value.
Without holding a lock throughout this and the actions taken depending
on the return value, garbage actions may be taken. Values that are
only slightly wrong might work OK, but this is not clear, and if it
does work then volatile variables and [non-]atomic accesses to the
variables to get it.

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: [PATCH] Document Linuxs memory barriers [try #2]
    ... strongly favours the use of explicit barriers except in small and specific cases. ... +order overlapping accesses correctly with respect to itself. ... +In all cases there are variants on a LOCK operation and an UNLOCK operation. ...
    (Linux-Kernel)
  • Lock EVERYTHING (for testing) [was: Re: Scaling noise]
    ... Is there a way we could get gcc to wrap EVERY memory access with some ... lock applied, then we can print a warning with the line number or drop ... Perhaps an even better solution would be to run an emulator. ... One problem is that we need to have metadata about memory accesses so we ...
    (Linux-Kernel)
  • Re: Atomicity on Pentium processor
    ... "Accesses to cacheable memory that are split across ... Which 'bus control signals', pray, are these? ... The Pentium uses the LOCK# signal to tell the system that the subsequent memory accesses must be executed in an atomic way. ...
    (comp.lang.asm.x86)
  • Re: sched_lock && thread_lock()
    ... 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. ... since locks are still needed for accesses to more ... Depending on the architecture PCPU may be more expensive than atomics so we decied not to use it all over. ...
    (freebsd-arch)
  • [patch 00/10] PI-futex: -V1
    ... We are pleased to announce "lightweight userspace priority inheritance" ... No registration, no extra kernel ... only a single owner may own a lock (i.e. no ... Priority Inheritance - why, oh why??? ...
    (Linux-Kernel)