Date: Mon, 21 May 2007 02:31:54 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Attilio Rao <attilio@FreeBSD.org> Cc: arch@FreeBSD.org, Bruce Evans <bde@optusnet.com.au> Subject: Re: sched_lock && thread_lock() Message-ID: <20070521022847.D679@10.0.0.1> In-Reply-To: <4651CE2F.8080908@FreeBSD.org> References: <20070520155103.K632@10.0.0.1> <20070521113648.F86217@besplex.bde.org> <20070520213132.K632@10.0.0.1> <4651CAB8.8070007@FreeBSD.org> <4651CE2F.8080908@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070521022847.D679>