Re: sched_lock && thread_lock()

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

_______________________________________________
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

  • sched_lock && thread_lock() (fwd)
    ... 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. ...
    (freebsd-performance)
  • Re: Do you protect your power switch with a lock?
    ... Do you protect your power switch with a lock? ... Search the archives at http://bama.ua.edu/archives/ibm-main.html ...
    (bit.listserv.ibm-main)
  • Re: Locking a picture or text box in a specific position
    ... You can lock the text box group by following these steps: ... you can protect the text box group as suggested in Jeffrey's mail. ... >> Anchor. ... >> select the picture.] ...
    (microsoft.public.mac.office.word)
  • Re: I need to password protect my pc at startup
    ... Is there a better way to protect my machine? ... New lock - custodial staff likely can ... Lock your office. ... to boot the computer and/or change BIOS settings should be easy ...
    (microsoft.public.windowsxp.basics)
  • Re: Problems using outlines on a protected sheet
    ... If you already have the outline applied, you can protect the worksheet in code ... Sub auto_open ... Don't forget to lock the VBA Project, ... > locked cells. ...
    (microsoft.public.excel.misc)