From owner-freebsd-arch@FreeBSD.ORG Mon May 21 15:13:08 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C5AD16A468 for ; Mon, 21 May 2007 15:13:08 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1F113C4B9 for ; Mon, 21 May 2007 15:13:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id w8so1017189mue for ; Mon, 21 May 2007 08:13:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=t/Zv342hRToloAYnInszY1704Mg6PsxP96Q4lNTP4aS7Or6hhRy9Uw1yHrRr7MKpzonv7R1tJurkbGd5F9nXeiuoBp0FkA//dA/+JGpCA0X9jcXPlmb4/aFPqZJEuIX76K6RwUlbHmIzwYaPzTAEr2o7WdtKYsVYYSm6Q9zMFIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=I7wQvD5mropa8tIZkempdbSvPA3kQKjBhq3oA2CpbfES7tTTEnpwLZAy3e8BtpcWYW1UrUoxiv5BNywwKDC9qdwGLmZXkDSaWzeuTHaxbJnw81mpMlqe4GTl/vfKvMr/mfjxrA7vpwQ16/QqreWcbBEof25/9X7kOzbOrCHa9fQ= Received: by 10.82.156.12 with SMTP id d12mr8854303bue.1179760384355; Mon, 21 May 2007 08:13:04 -0700 (PDT) Received: from ?172.31.5.25? ( [89.97.252.178]) by mx.google.com with ESMTP id y34sm273009iky.2007.05.21.08.13.00; Mon, 21 May 2007 08:13:01 -0700 (PDT) Message-ID: <46522846.5000707@FreeBSD.org> Date: Tue, 22 May 2007 01:16:22 +0200 From: Attilio Rao User-Agent: Thunderbird 1.5 (X11/20060526) MIME-Version: 1.0 To: Bruce Evans 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> <20070521022847.D679@10.0.0.1> <20070521195811.G56785@delplex.bde.org> <4651FCB5.7070604@FreeBSD.org> <20070521225032.C57233@delplex.bde.org> In-Reply-To: <20070521225032.C57233@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Attilio Rao Cc: arch@freebsd.org Subject: Re: sched_lock && thread_lock() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2007 15:13:08 -0000 Bruce Evans wrote: > Just change the PCPU_LAZY_INC() macro to access the non-per-cpu global, > using the same locking as you use for the non-pcpu access method. I > do this in some (old) sys trees for the !SMP case. This gives a small > unpessimization and fixes reading the values from dead kernels, but > only in the !SMP case. I also remove pc_cnt from the pcpu data in the > !SMP case. This is a smaller optimization and requires larger changes > to remove adding up the pcpu data in vm_meter.c. The adding up can > be left unchanged since it becomes a no-op if the data is left at all > zeros. In the old sys trees, there is no locking for individual accesses, > so PCPU_LAZY_INC(var) becomes (++(var)). In the current tree, > PCPU_LAZY_INC(var) is (++()) written in asm for some arches to > ensure that it is atomic with respect to interrupts on these arches. > Atomicness with respect to interrupts is necessary and sufficient for > the non-per-cpu global !SMP case too. So you want these fields to be nomore per-cpu entirely, ok, now I got what you mean. > Bugs found while grepping for sched_locking of VMCNT fields: > - v_trap is supposed to be updated by PCPU_LAZY_INC(), but subr_trap.c > updates it by VMCNT_ADD(). The direct access used to be perfectly > unlocked > and non-atomic, since it occurs immediately after releasing sched_lock > and just used "++". Now it is atomic and a micro-pessimization. > - v_trap's name is now hidden by the macro so grepping for it doesn't work. Great, this is a bug introduced in old code that I didn't catch. I'm going to switch it to PCPU_LAZY_INC. Anyways you can grap those in this way (assuming you are in /usr/src/sys/): $ grep -r trap * | grep VMCNT_ > Non(?)-bugs found while grepping for VMCNT: > - most updates of v_free_count are via pq->lcnt++ and pq->lcnt-- in > vm_page.c and vm_pageq. pq->lcnt is VMCNT_PTR(&cnt.vm_free_count) > for all pq. The locking for this seems to be correct except of course > in sysctls, since it uses vm_page_queue_free_mtx and never needed > VMCNT access methods. The unneeded VMCNT_GET()s for this alone comprise > about 1/3 of the VMCNT_GET()s in vm. You have to consider that VMCNT_*() is used also for dealing with 'volatilization' of struct vmmeter cnt. it, so, entirely hides all implementation details for vmmeter counter. VMCNT_PTR is currently the right way to access to these datas if you want to hide the volatile to sysctls (and please note that VMCNT_GET() doesn't add any pessimization to the current code). Thanks, Attilio