From owner-freebsd-arch@FreeBSD.ORG Sun Jun 10 04:46: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 9B5BB16A421 for ; Sun, 10 Jun 2007 04:46:08 +0000 (UTC) (envelope-from lankfordandrew@charter.net) Received: from que02.charter.net (que02.charter.net [209.225.8.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3586E13C455 for ; Sun, 10 Jun 2007 04:46:07 +0000 (UTC) (envelope-from lankfordandrew@charter.net) Received: from aa04.charter.net ([10.20.200.156]) by mtai04.charter.net (InterMail vM.7.08.02.00 201-2186-121-20061213) with ESMTP id <20070610040703.XAGQ1555.mtai04.charter.net@aa04.charter.net> for ; Sun, 10 Jun 2007 00:07:03 -0400 Received: from [192.168.15.100] (really [75.138.222.96]) by aa04.charter.net with ESMTP id <20070610040703.UCPT26958.aa04.charter.net@[192.168.15.100]> for ; Sun, 10 Jun 2007 00:07:03 -0400 Message-ID: <466B78E6.5060201@charter.net> Date: Sun, 10 Jun 2007 00:07:02 -0400 From: Andrew Lankford User-Agent: Thunderbird 2.0.0.0 (X11/20070523) MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Chzlrs: 0 Cc: Subject: Bikeshed: Moving around the var/db/pkg hierarchy X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 04:46:08 -0000 Just wondering, but what are the reasons for putting port building options and package system meta data in the /var slice? Maybe I'm just not the sort of FreeBSD user who would see a need to reserve a gigabyte or more for the /var partition, but /var/db/pkg keeps getting larger over successive upgrades even though the rest of /var really doesn't (assuming that programs don't dump all sorts of unclaimed rubbish in /var/tmp). Why not place ports/package info in the same part of the tree where package files typically go, /usr/local? Andrew Lankford From owner-freebsd-arch@FreeBSD.ORG Sun Jun 10 06:31:38 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 D85E816A41F for ; Sun, 10 Jun 2007 06:31:38 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id B36BE13C44C for ; Sun, 10 Jun 2007 06:31:38 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1838077waf for ; Sat, 09 Jun 2007 23:31:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Zrpw3ZT904qJVkQJpzhupYw6kN3Bq5uFVAPP96QVHNd7+3xl98gtSZI0T0FqX455mdjVhUmdtdspQosUm3838nsR0thLH8mT64hIQE1QWkawi8YqpAEqYfVecZ/Re+J000HYz9B3UDZFSHNjEfY71ocTASIDYiMVp8IjAt12qMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=D8SL8/LDRl6plzk37cKYPe2hNII4rLMxLgZroAw99CmjGpnbai8J2Dkbh1rDP+vaqJKX9mivXRNchhKra75Q8CHfvhIWwSuB3ih3OjpVSkPVLm6SV7vmWAN1w6R/laNEzl6AStKd8/cecSSwdazYJYvTY/vT2Q++fiVi6xyGC2g= Received: by 10.114.152.17 with SMTP id z17mr4194808wad.1181455442510; Sat, 09 Jun 2007 23:04:02 -0700 (PDT) Received: by 10.114.194.13 with HTTP; Sat, 9 Jun 2007 23:04:02 -0700 (PDT) Message-ID: Date: Sun, 10 Jun 2007 10:04:02 +0400 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Andrew Lankford" In-Reply-To: <466B78E6.5060201@charter.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <466B78E6.5060201@charter.net> X-Google-Sender-Auth: 617e01aeb39942db Cc: arch@freebsd.org Subject: Re: Bikeshed: Moving around the var/db/pkg hierarchy X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 06:31:38 -0000 On 6/10/07, Andrew Lankford wrote: > Just wondering, but what are the reasons for putting port building > options and package system meta data in the /var slice? Maybe I'm just > not the sort of FreeBSD user who would see a need to reserve a gigabyte > or more for the /var partition, but /var/db/pkg keeps getting larger > over successive upgrades even though the rest of /var really doesn't > (assuming that programs don't dump all sorts of unclaimed rubbish in > /var/tmp). Why not place ports/package info in the same part of the > tree where package files typically go, /usr/local? csup/cvsup, portsnap, freebsd-update, mysql, e-mail, logs, ..., ..., ... all use it because they've all traditionally used it for ages and it's written down in hier(8) From owner-freebsd-arch@FreeBSD.ORG Mon Jun 11 17:58:27 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 B7D6D16A468 for ; Mon, 11 Jun 2007 17:58:27 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 5975713C4AE for ; Mon, 11 Jun 2007 17:58:27 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 0 with SMTP; 11 Jun 2007 17:31:45 -0000 Date: Mon, 11 Jun 2007 20:31:48 +0300 From: Nikolay Pavlov To: Andrew Lankford Message-ID: <20070611173148.GC36573@zone3000.net> References: <466B78E6.5060201@charter.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466B78E6.5060201@charter.net> X-Operating-System: FreeBSD 6.2-RELEASE-p4 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: arch@freebsd.org Subject: Re: Bikeshed: Moving around the var/db/pkg hierarchy X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 17:58:27 -0000 On Sunday, 10 June 2007 at 0:07:02 -0400, Andrew Lankford wrote: > Just wondering, but what are the reasons for putting port building options and package system meta data in the /var slice? Maybe I'm just not the sort of FreeBSD user who would > see a need to reserve a gigabyte or more for the /var partition, but /var/db/pkg keeps getting larger over successive upgrades even though the rest of /var really doesn't > (assuming that programs don't dump all sorts of unclaimed rubbish in /var/tmp). Why not place ports/package info in the same part of the tree where package files typically go, > /usr/local? > > Andrew Lankford > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" This is because on the large environments the ports tree is usually mounted from the NFS repository on every other server. The much better question is why portupgrade is using /usr/ports directory by default. # ENV['PORTSDIR'] ||= '/usr/ports' # ENV['PORTS_INDEX'] ||= ENV['PORTSDIR'] + '/INDEX' # ENV['PORTS_DBDIR'] ||= ENV['PORTSDIR'] # ENV['PKG_DBDIR'] ||= '/var/db/pkg' I think the more consistent way is ENV['PORTS_DBDIR'] ||= '/var/db/ports' However this is just IMHO. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-arch@FreeBSD.ORG Tue Jun 12 06:59:43 2007 Return-Path: X-Original-To: freebsd-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 73A7A16A469; Tue, 12 Jun 2007 06:59:43 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4804A13C45E; Tue, 12 Jun 2007 06:59:43 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l5C6xdFe085573 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 02:59:41 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 11 Jun 2007 23:59:08 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: John Baldwin In-Reply-To: <20070605114745.I606@10.0.0.1> Message-ID: <20070611235531.F60816@10.0.0.1> References: <20070604220649.E606@10.0.0.1> <200706051012.18864.jhb@freebsd.org> <20070605114745.I606@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 12 Jun 2007 11:21:00 +0000 Cc: marcel@freebsd.org, kmacy@freebsd.org, benno@freebsd.org, marius@freebsd.org, arch@freebsd.org, jake@freebsd.org, freebsd-arch@freebsd.org, tmm@freebsd.org, cognet@freebsd.org, grehan@freebsd.org Subject: Re: New cpu_switch() and cpu_throw(). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 06:59:43 -0000 I have decided to abandon the architecture specific cpu_throw() in favor of an approach that is completely MI. The new approach will be to use an atomic int in the proc to track the number of threads in cpu_throw(). The waiting thread will just yield until that count hits 0, which will likely at most require one context switch ever as there is no opportunity for a thread to block after this count is bumped. I'm going to commit this change fairly quickly as a couple of people have reported hiting this exit race on 4-8 core machines. You can review the diff here: http://people.freebsd.org/~jeff/exitthread.diff The cpu_throw() changes will still be required for architectures which wish to continue to support ULE. This is advisable for any arch that supports SMP. Thanks, Jeff On Tue, 5 Jun 2007, Jeff Roberson wrote: > On Tue, 5 Jun 2007, John Baldwin wrote: > >> On Tuesday 05 June 2007 01:32:46 am Jeff Roberson wrote: >>> For every architecture we need to support a new features in cpu_switch() >>> and cpu_throw() before they can support per-cpu schedlock. I'll describe >>> those below. I'm soliciting help or advice in implementing these on >>> platforms other than x86, and amd64, especially on ia64 where things are >>> implemented in C! >>> >>> I checked in the new version of cpu_switch() for amd64 today after >>> threadlock went in. Basically, we have to release a thread's lock when >>> it's switched out and acquire a lock when it's switched in. >>> >>> The release must happen after we're totally done with the stack and >>> vmspace of the thread to be switched out. On amd64 this meant after we >>> clear the active bits for tlb shootdown. The release actually makes use >>> of a new 'mtx' argument to cpu_switch() and sets the td_lock pointer to >>> this argument rather than unlocking a real lock. td_lock has previously >>> been set to the blocked lock, which is always blocked. Threads >>> spinning in thread_lock() will notice the td_lock pointer change and >>> acquire the new lock. So this is simple, just a non-atomic store with a >>> pointer passed as an argument. On amd64: >>> >>> movq %rdx, TD_LOCK(%rdi) /* Release the old thread */ >>> >>> The acquire part is slightly more complicated and involves a little loop. >>> We don't actually have to spin trying to lock the thread. We just spin >>> until it's no longer set to the blocked lock. The switching thread >>> already owns the per-cpu scheduler lock for the current cpu. If we're >>> switching into a thread that is set to the blocked_lock another cpu is >>> about to set it to our current cpu's lock via the mtx argument mentioned >>> above. On amd64 we have: >>> >>> /* Wait for the new thread to become unblocked */ >>> movq $blocked_lock, %rdx >>> 1: >>> movq TD_LOCK(%rsi),%rcx >>> cmpq %rcx, %rdx >>> je 1b >> >> If this is to handle a thread migrating from one CPU to the next (and >> there's >> no interlock to control migration, otherwise you wouldn't have to spin >> here) >> then you will need memory barriers on the first write (i.e. the first write >> above should be an atomic_store_rel()) and the equivalent of an _acq >> barrier >> here. > > So, thanks for pointing this out. Attilio also mentions that on x86 and > amd64 we need a pause in the wait loop. As we discussed, we can just use > sfence rather than atomics on amd64, however, x86 will need atomics since you > can't rely on the presence of *fence. Other architectures will have to > ensure memory ordering as appropriate. > > Jeff > >> >> -- >> John Baldwin >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Jun 12 06:59:43 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 73A7A16A469; Tue, 12 Jun 2007 06:59:43 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4804A13C45E; Tue, 12 Jun 2007 06:59:43 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l5C6xdFe085573 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 12 Jun 2007 02:59:41 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 11 Jun 2007 23:59:08 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: John Baldwin In-Reply-To: <20070605114745.I606@10.0.0.1> Message-ID: <20070611235531.F60816@10.0.0.1> References: <20070604220649.E606@10.0.0.1> <200706051012.18864.jhb@freebsd.org> <20070605114745.I606@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 12 Jun 2007 11:21:00 +0000 Cc: marcel@freebsd.org, kmacy@freebsd.org, benno@freebsd.org, marius@freebsd.org, arch@freebsd.org, jake@freebsd.org, freebsd-arch@freebsd.org, tmm@freebsd.org, cognet@freebsd.org, grehan@freebsd.org Subject: Re: New cpu_switch() and cpu_throw(). X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 06:59:43 -0000 I have decided to abandon the architecture specific cpu_throw() in favor of an approach that is completely MI. The new approach will be to use an atomic int in the proc to track the number of threads in cpu_throw(). The waiting thread will just yield until that count hits 0, which will likely at most require one context switch ever as there is no opportunity for a thread to block after this count is bumped. I'm going to commit this change fairly quickly as a couple of people have reported hiting this exit race on 4-8 core machines. You can review the diff here: http://people.freebsd.org/~jeff/exitthread.diff The cpu_throw() changes will still be required for architectures which wish to continue to support ULE. This is advisable for any arch that supports SMP. Thanks, Jeff On Tue, 5 Jun 2007, Jeff Roberson wrote: > On Tue, 5 Jun 2007, John Baldwin wrote: > >> On Tuesday 05 June 2007 01:32:46 am Jeff Roberson wrote: >>> For every architecture we need to support a new features in cpu_switch() >>> and cpu_throw() before they can support per-cpu schedlock. I'll describe >>> those below. I'm soliciting help or advice in implementing these on >>> platforms other than x86, and amd64, especially on ia64 where things are >>> implemented in C! >>> >>> I checked in the new version of cpu_switch() for amd64 today after >>> threadlock went in. Basically, we have to release a thread's lock when >>> it's switched out and acquire a lock when it's switched in. >>> >>> The release must happen after we're totally done with the stack and >>> vmspace of the thread to be switched out. On amd64 this meant after we >>> clear the active bits for tlb shootdown. The release actually makes use >>> of a new 'mtx' argument to cpu_switch() and sets the td_lock pointer to >>> this argument rather than unlocking a real lock. td_lock has previously >>> been set to the blocked lock, which is always blocked. Threads >>> spinning in thread_lock() will notice the td_lock pointer change and >>> acquire the new lock. So this is simple, just a non-atomic store with a >>> pointer passed as an argument. On amd64: >>> >>> movq %rdx, TD_LOCK(%rdi) /* Release the old thread */ >>> >>> The acquire part is slightly more complicated and involves a little loop. >>> We don't actually have to spin trying to lock the thread. We just spin >>> until it's no longer set to the blocked lock. The switching thread >>> already owns the per-cpu scheduler lock for the current cpu. If we're >>> switching into a thread that is set to the blocked_lock another cpu is >>> about to set it to our current cpu's lock via the mtx argument mentioned >>> above. On amd64 we have: >>> >>> /* Wait for the new thread to become unblocked */ >>> movq $blocked_lock, %rdx >>> 1: >>> movq TD_LOCK(%rsi),%rcx >>> cmpq %rcx, %rdx >>> je 1b >> >> If this is to handle a thread migrating from one CPU to the next (and >> there's >> no interlock to control migration, otherwise you wouldn't have to spin >> here) >> then you will need memory barriers on the first write (i.e. the first write >> above should be an atomic_store_rel()) and the equivalent of an _acq >> barrier >> here. > > So, thanks for pointing this out. Attilio also mentions that on x86 and > amd64 we need a pause in the wait loop. As we discussed, we can just use > sfence rather than atomics on amd64, however, x86 will need atomics since you > can't rely on the presence of *fence. Other architectures will have to > ensure memory ordering as appropriate. > > Jeff > >> >> -- >> John Baldwin >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Wed Jun 13 08:58:58 2007 Return-Path: X-Original-To: freebsd-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 B1B9216A468 for ; Wed, 13 Jun 2007 08:58:58 +0000 (UTC) (envelope-from olivier.freebsduser@free.fr) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4ABE013C468 for ; Wed, 13 Jun 2007 08:58:58 +0000 (UTC) (envelope-from olivier.freebsduser@free.fr) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-g20.free.fr (Postfix) with ESMTP id C0B001263F43 for ; Wed, 13 Jun 2007 10:25:47 +0200 (CEST) Received: from lon92-4-82-226-188-149.fbx.proxad.net (lon92-4-82-226-188-149.fbx.proxad.net [82.226.188.149]) by smtp6-g19.free.fr (Postfix) with ESMTP id CF526B5B02 for ; Wed, 13 Jun 2007 10:25:46 +0200 (CEST) From: Olivier Certner To: freebsd-arch@freebsd.org Date: Wed, 13 Jun 2007 10:23:15 +0200 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706131023.15778.olivier.freebsduser@free.fr> Subject: How to allow userland to access per-thread CPU time information? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 08:58:58 -0000 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Hi all, In the emulator project I work on currently, I need to know the time CPUs= =20 have spent executing a particular thread of the current process. Basically,= =20 this is the same functionality (actually, a subset) as provided by=20 getrusage(), except I would want it at the thread-level granularity. In the= =20 rusage structure, I'm mostly interested by the ru_{u,s}time fields. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I've looked around for seve= ral solutions. The POSIX threads interface=20 doesn't seem to define any time reporting function. In FreeBSD, no=20 non-portable extension to this interface provides the functionality. Inside= =20 the kernel (I'm speaking about RELENG_6 in the following), the thread=20 structure has fields to keep track of the CPU usage (td_{s,uu,us}ticks). I= =20 agree one such structure represents a KSE context, not exactly a "thread" a= s=20 seen from userland. But the KSE system seems to provide a solution because = it=20 defines different mailboxes for userland threads, each having accounting=20 fields (tm_{u,s}ticks). =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0So, the only thing I seem t= o miss here is some support to retrieve=20 this information from the threading library. Hence my questions: does anyon= e=20 have begun to work on such a functionality? If not, are you aware of any=20 attempt of standardizing such an access? I would be glad to help design=20 and/or implement this functionality in FreeBSD's threading libraries. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For completeness, I've also= investigated the values that the "who"=20 parameter of getrusage can take in several OSes, because some of the latter= =20 use it as a way to return per-thread statistics. It seems that only a few o= f=20 them implement other values than RUSAGE_SELF and RUSAGE_CHILDREN. Some (suc= h=20 as Solaris or, since recently, Linux) support the RUSAGE_THREAD value. I=20 don't think there is (and will be one day) consensus on whether the N:M=20 threading model is definitely inferior to the 1:1 model (even in CURRENT, t= he=20 old N:M library is still there as libkse, although no more the default), so= ,=20 at the moment, I don't find this solution very elegant, since the kernel is= =20 not necessarily aware of all userland threads, and if it is, going to the=20 kernel to finally retrieve the information from the userland thread schedul= er=20 library isn't very efficient. I would suggest rather a (non-?)portable=20 addition to the pthread interface, such as a pthread_getrusage function. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0There has been a recent dis= cussion on this topic on the=20 LKML. Here's a link to a message from Ulrich Drepper that goes in the same= =20 direction: http://www.opensubscriber.com/message/linux-kernel%40vger.kernel.org/661613= 3.html .=20 Time counters were my primary interest, but more generally, access to a=20 per-thread ressource usage report seems desirable. So far, I've not looked = in=20 detail which rusage structure fields would be relevant for threads. Any directions or thoughts? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Regards, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Olivier From owner-freebsd-arch@FreeBSD.ORG Wed Jun 13 10:34:31 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 6EBA116A41F; Wed, 13 Jun 2007 10:34:31 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7A713C45A; Wed, 13 Jun 2007 10:34:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5865545696; Wed, 13 Jun 2007 12:16:07 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F397545683; Wed, 13 Jun 2007 12:16:02 +0200 (CEST) Date: Wed, 13 Jun 2007 12:15:34 +0200 From: Pawel Jakub Dawidek To: Howard Su Message-ID: <20070613101534.GA9200@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: alc@freebsd.org, arch@freebsd.org Subject: Re: help on lock around vm_page X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 10:34:31 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 07, 2007 at 12:18:10AM +0800, Howard Su wrote: > I want some helps from VM guru. I try to fix a panic in tmpfs. In > order to push tmpfs into -Current, I really want some help to solve > this. >=20 > 1. we allocate an object from vm_pager_alloc(OBJT_SWAP, ...) when create = a file. > 2. the panic is during handling write op: > a) find the first page we want to write > b) call vm_page_grab to get the page from object. > c) call use sf_buf_alloc to map it into kernel_map > d) use uiomove to move the data > e) mark page as dirty > f) loop to a until all pages are handled. >=20 > there is a race condition. while doing b-c & e, we hold the > OBJ_LOCK/page_queue_lock. when doing d, we have to drop the locks to > call uiomove. When calling uio move, the page may moved to cache queue > since in that time it is not dirty. >=20 > There is a solution that we allocate a page buffer. Before a), we > uiomove it to the buffer and replace uiomove with a bcopy in d). Then, > we can hold lock in b - e. I feel this will cause performance problem. >=20 > For the detailed code, please check: > http://perforce.freebsd.org/fileViewer.cgi?FSPC=3D//depot/user/howardsu/t= russ/sys/fs/tmpfs/tmpfs%5fvnops.c&REV=3D30 >=20 > function: tmpfs_uio_xfer() >=20 > Any idea to close this race condition? >=20 > PS: If you can review my code about usage of vm, it will be appreciated. I've no time to review your code atm, but you may want to look how it is done in ZFS, maybe this will give you hint. Check out zfs_{read,write} and mapped{read,write} functions in sys/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGb8PGForvXbEpPzQRAsslAKDlR6mDBMaBghsWnhqbLon6gPGjIgCfWMZJ W0nWHETWr2QoZ6Pq2KyR/c4= =7v97 -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-arch@FreeBSD.ORG Thu Jun 14 06:41:17 2007 Return-Path: X-Original-To: freebsd-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 3FFCA16A400 for ; Thu, 14 Jun 2007 06:41:17 +0000 (UTC) (envelope-from cadastrosonline@yahoo.com.br) Received: from web57302.mail.re1.yahoo.com (web57302.mail.re1.yahoo.com [66.196.100.38]) by mx1.freebsd.org (Postfix) with SMTP id 0292513C45E for ; Thu, 14 Jun 2007 06:41:16 +0000 (UTC) (envelope-from cadastrosonline@yahoo.com.br) Received: (qmail 96551 invoked by uid 60001); 14 Jun 2007 06:14:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=mIowa+sp/hLdDy1BusgEVKL9I1szNSzz3TmMNIL/k4yW8EFxgfBqBIzZaW6CHz1ltOHe2vYXLI0pfbEkipQLx2W3M7ZiUZe3dLQc0vzrJKfSb6Wgojl5VcLTNx6TREco5ttNrX74ZDVhMyc20jTP5hqMsS3pj1yDzgKmTMFwwY0=; X-YMail-OSG: gdsO5XsVM1lUWRLkPVYBo_1_lcqD_jk1zOGrn5fjTJHzCOWS61GcOIwTG54xVZx8afWFgzZHeRMKbnMmzYNW1.Q.mg-- Received: from [209.73.178.42] by web57302.mail.re1.yahoo.com via HTTP; Wed, 13 Jun 2007 23:14:35 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Wed, 13 Jun 2007 23:14:35 -0700 (PDT) From: cadastrosonline cadastrosonline To: freebsd-arch@freebsd.org MIME-Version: 1.0 Message-ID: <666957.96491.qm@web57302.mail.re1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Memory mannagment X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 06:41:17 -0000 First of all,=0A=0A"Each process has its own private address space. The add= ress space is initially divided=0Ainto three logical segments: text,=0Adata= , and stack. "=0A=0ABut if the address is just something like 343556 then h= ow does it really work? The memory is divided into segments is that what it= means?=0A=0A"The data segment contains the initialized and uninitialized d= ata portions of a program"=0A=0AIs it talking about multithreading? I COULD= NT FIND anything talking about how freebsd deals with multithreading, just = found out it does it by man pthread.=0A=0ATell me anything else interesting= to know about memory mannagment, does it use any algorithm to substitute a= page when out of pages in memory? such as "second chance" "fifo" "lru" (la= st recently used) "nfu" (not frequently used) and so on? I am studying free= bsd but sometimes I am out of ways to find out, yes I am reading the handbo= ok about memory mannagment as you can see my quotes but sometimes I don't u= nderstand.=0A=0AThanks in advance.=0A=0A=0A=0A=0A =0A________________= ____________________________________________________________________=0ANovo= Yahoo! Cad=EA? - Experimente uma nova busca.=0Ahttp://yahoo.com.br/oqueeug= anhocomisso From owner-freebsd-arch@FreeBSD.ORG Thu Jun 14 07:08:08 2007 Return-Path: X-Original-To: freebsd-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 55B7116A474 for ; Thu, 14 Jun 2007 07:08:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 43E2113C480 for ; Thu, 14 Jun 2007 07:08:07 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5EFC51A4D80; Thu, 14 Jun 2007 00:07:41 -0700 (PDT) Date: Thu, 14 Jun 2007 00:07:41 -0700 From: Alfred Perlstein To: cadastrosonline cadastrosonline Message-ID: <20070614070741.GP96936@elvis.mu.org> References: <666957.96491.qm@web57302.mail.re1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <666957.96491.qm@web57302.mail.re1.yahoo.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-arch@freebsd.org Subject: Re: Memory mannagment X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 07:08:08 -0000 * cadastrosonline cadastrosonline [070613 23:42] wrote: > First of all, > > "Each process has its own private address space. The address space is initially divided > into three logical segments: text, > data, and stack. " > > But if the address is just something like 343556 then how does it really work? The memory is divided into segments is that what it means? Each process has a seperate virtual vmspace, this means that address 343556 in process A can map to a different physical address in process B. > "The data segment contains the initialized and uninitialized data portions of a program" > > Is it talking about multithreading? I COULDNT FIND anything talking about how freebsd deals with multithreading, just found out it does it by man pthread. The data segment has nothing to do with multithreading other than as a shared memory space for use by multiple threads. > Tell me anything else interesting to know about memory mannagment, does it use any algorithm to substitute a page when out of pages in memory? such as "second chance" "fifo" "lru" (last recently used) "nfu" (not frequently used) and so on? I am studying freebsd but sometimes I am out of ways to find out, yes I am reading the handbook about memory mannagment as you can see my quotes but sometimes I don't understand. FreeBSD uses a LRU. If you want to learn more I would advise you to purchase "The Design and Implementation of the FreeBSD Operating System" by McKusick. You can also use the FreeBSD mailing lists if you so desire. Good luck and enjoy. (btw, FreeBSD is how I learned most of my deeper OS level concepts, so you're in the right place.) -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Thu Jun 14 17:04:04 2007 Return-Path: X-Original-To: freebsd-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 686B616A480 for ; Thu, 14 Jun 2007 17:04:04 +0000 (UTC) (envelope-from cadastrosonline@yahoo.com.br) Received: from web57302.mail.re1.yahoo.com (web57302.mail.re1.yahoo.com [66.196.100.38]) by mx1.freebsd.org (Postfix) with SMTP id 1E27813C448 for ; Thu, 14 Jun 2007 17:04:03 +0000 (UTC) (envelope-from cadastrosonline@yahoo.com.br) Received: (qmail 24717 invoked by uid 60001); 14 Jun 2007 17:04:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=HMN+o8v0Eicz5cZafTfC0KRbBl/KlW22257TU+HAMIzH12BH6wsYP3QcVNSUCBOAhn7sca3u0QML5QuPtMt+2jaT/cwfRzVSFjt4ZTph3+wha+2UtKL5pRi/nnbrwSp0SsPM4ebtRUKeEPl0ic/UuX3Gq4ffvm7BPLkCPLHD6kI=; X-YMail-OSG: SHQd9aIVM1kcqJd5XECxPAHCyokLxGksvpdIjtDVbpw1SHLiu9feGF2p9ejpD0VGZj_wwCRw0ljYDH5K_3hLz4RHBO2QrGuADAvD Received: from [69.147.97.214] by web57302.mail.re1.yahoo.com via HTTP; Thu, 14 Jun 2007 10:04:03 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Thu, 14 Jun 2007 10:04:03 -0700 (PDT) From: cadastrosonline cadastrosonline To: fbsd arch MIME-Version: 1.0 Message-ID: <497837.24344.qm@web57302.mail.re1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: VM X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 17:04:04 -0000 "FreeBSD's memory allocation code implements page coloring optimizations, w= hich means=0Athat the memory allocation code will attempt to locate free pa= ges that are contiguous=0Afrom the point of view of the cache. For example,= if page 16 of physical memory is=0Aassigned to page 0 of a process's virtu= al memory and the cache can hold 4 pages, the page=0Acoloring code will not= assign page 20 of physical memory to page 1 of a process's virtual=0Amemor= y."=0A=0AFrom fbsd books, I don't understand why it links page 16 of physic= al memory to page 0 then talks about page 20 of physcal memory to page 1, o= k it will say it will sign to page 21 because of the page coloring, but tha= ts not what i didnt get.=0A=0AIf the cache holds 4 pages, why wouldn't the = physical page 20 sign to page 4 or 8 instead? Why 1? lol :> i see its signi= ng the VM as 0,1,2,3,4 and the physical as 4,8,16,20...could anyone explain= that?=0A=0A=0A=0A=0A =0A____________________________________________= ________________________________________=0ANovo Yahoo! Cad=EA? - Experiment= e uma nova busca.=0Ahttp://yahoo.com.br/oqueeuganhocomisso From owner-freebsd-arch@FreeBSD.ORG Fri Jun 15 07:41:37 2007 Return-Path: X-Original-To: freebsd-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 5356E16A469 for ; Fri, 15 Jun 2007 07:41:37 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id F283813C465 for ; Fri, 15 Jun 2007 07:41:31 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id h28so695504wxd for ; Fri, 15 Jun 2007 00:41:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=enMM8ypIyEwlblfjXcON+DP112MqUzU1v+MLeGUWwQrbRJEBCZID9YuasCd4A03NMZe4TEahXDeVaBKJzxMr9hxZs+0w0HPFUEDmhCqVfRll4LTouINxdpAT9A/Of04QFmAa1y1LtK9RC+Tt5Voyq87UI7KWFGxw2zf2KUUIamw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l9gbsb4x9hUYcJUhF5Mw9AFnebbZzzU2RkNqLcNHgofcKpGIdKkF5+BTzTwqFmL2En6mVfktg6wBrniXi/wPkaTmk3DDIN4lf4uvbXkfCaUI7GbXGPBjjnWZPl4hInPilYGuDU0ZqNj5s81CaFFRqP5N/LILNb50pNuNsiYesRk= Received: by 10.90.105.19 with SMTP id d19mr2283540agc.1181891613032; Fri, 15 Jun 2007 00:13:33 -0700 (PDT) Received: by 10.90.119.18 with HTTP; Fri, 15 Jun 2007 00:13:32 -0700 (PDT) Message-ID: Date: Fri, 15 Jun 2007 10:13:32 +0300 From: "Ivo Vachkov" To: "cadastrosonline cadastrosonline" In-Reply-To: <497837.24344.qm@web57302.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <497837.24344.qm@web57302.mail.re1.yahoo.com> Cc: fbsd arch Subject: Re: VM X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 07:41:37 -0000 On 6/14/07, cadastrosonline cadastrosonline wrote: > "FreeBSD's memory allocation code implements page coloring optimizations,= which means > that the memory allocation code will attempt to locate free pages that ar= e contiguous > from the point of view of the cache. For example, if page 16 of physical = memory is > assigned to page 0 of a process's virtual memory and the cache can hold 4= pages, the page > coloring code will not assign page 20 of physical memory to page 1 of a p= rocess's virtual > memory." > > From fbsd books, I don't understand why it links page 16 of physical memo= ry to page 0 then talks about page 20 of physcal memory to page 1, ok it wi= ll say it will sign to page 21 because of the page coloring, but thats not = what i didnt get. > > If the cache holds 4 pages, why wouldn't the physical page 20 sign to pag= e 4 or 8 instead? Why 1? lol :> i see its signing the VM as 0,1,2,3,4 and t= he physical as 4,8,16,20...could anyone explain that? > > I think, if virtual memory page 0 maps on physical memory page 16, then virtual memory page 1 would map to physical memory page 17 and that's the main idea. Instead, if you map vm page 1 to phys page 20 this will require cache invalidation on access. > > > _________________________________________________________________________= ___________ > Novo Yahoo! Cad=EA? - Experimente uma nova busca. > http://yahoo.com.br/oqueeuganhocomisso > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > --=20 "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie