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