From owner-freebsd-arch@FreeBSD.ORG Sun Jul 13 07:22:57 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F6B106566B; Sun, 13 Jul 2008 07:22:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 305088FC18; Sun, 13 Jul 2008 07:22:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 376B91CCA9; Sun, 13 Jul 2008 09:22:54 +0200 (CEST) Date: Sun, 13 Jul 2008 09:22:54 +0200 From: Ed Schouten To: FreeBSD Current , FreeBSD Arch Message-ID: <20080713072254.GX14567@hoeg.nl> References: <20080702190901.GS14567@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/jamoCVtoCI0aYZY" Content-Disposition: inline In-Reply-To: <20080702190901.GS14567@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Marcel Moolenaar , Philip Paeps Subject: Re: MPSAFE TTY schedule 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, 13 Jul 2008 07:22:57 -0000 --/jamoCVtoCI0aYZY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, * Ed Schouten wrote: > July 13 2008: > Make uart(4) the default serial port driver, instead of sio(4). > sio(4) has not been ported to the new TTY layer and is very hard > to do so. uart(4) has been proven to be more portable than > sio(4) and already supports the hardware we need. Just a small message to inform that I've just changed the default serial port driver on amd64 and i386 to uart(4) (see SVN commit 180487). I've decided to leave pc98 as it is now, because I'd rather let the respective maintainers look into this. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --/jamoCVtoCI0aYZY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh5rU4ACgkQ52SDGA2eCwX46QCfakX8RJ4yK4ruWLSlgswPxi5C vgUAnjFKJ0Sati8+XcaJ9Hydzqzo1asT =+8SM -----END PGP SIGNATURE----- --/jamoCVtoCI0aYZY-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 14 04:20:29 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C501065674 for ; Mon, 14 Jul 2008 04:20:29 +0000 (UTC) (envelope-from sson@freebsd.org) Received: from www.son.org (son.org [199.239.233.23]) by mx1.freebsd.org (Postfix) with ESMTP id 904D28FC19 for ; Mon, 14 Jul 2008 04:20:29 +0000 (UTC) (envelope-from sson@freebsd.org) Received: from mactel.local (ppp-68-90-8-92.dsl.rcsntx.swbell.net [68.90.8.92]) (authenticated bits=0) by www.son.org (8.13.6.20060614/8.13.6) with ESMTP id m6E4KRHA098475; Sun, 13 Jul 2008 23:20:28 -0500 (CDT) Message-ID: <487AD49F.6040304@freebsd.org> Date: Sun, 13 Jul 2008 23:22:55 -0500 From: Stacey Son User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008070703) MIME-Version: 1.0 To: Kostik Belousov References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080712045837.GD17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Gallatin , freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver 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, 14 Jul 2008 04:20:29 -0000 Kostik Belousov wrote: > Most likely, I miss some obvious reason there. But for me it looks > like you do it in the reverse. The natural setup would be to require > userspace to supply an allocated memory to the driver, and then the > driver fills the memory with symbol table. This solves the problem of > exhaustion of kernel address space. > The snapshot of the consolidated symbol table is made when /dev/ksyms is opened. The storage for the snapshot is allocated in the memory map of the calling process. No kernel address space is used for the snapshot. A temporary buffer is allocated in kernel space in the read() handler (ksyms_read). Right now, for a read, it does two copies: one from user space to the temporary kernel space buffer and a second copy from the kernel space temp buffer and back out to user space. Ideally, it would be nice to do just one user space to user space copy directly in the kernel. > As usual, when user-supplied region is too small, driver shall return > both an error and new required size. It is understandable that the size > is volatile and may be too small for the next call too. But, in fact, > kernel symtable does not change too often, so I think even the one > iteration mostly succeed. > The reason the driver tries three times to create a valid snapshot is I couldn't figure out a way (without creating a lock reversal) to temporarily keep modules from being loaded or unloaded while the snapshot is created. I agree that it should be able to create the snapshot on the first iteration in most cases. BTW, you may have noticed the ksyms driver now uses your per-open file private data code which I like much better than using clone_create() for per-descriptor storage. Best Regards, -stacey. From owner-freebsd-arch@FreeBSD.ORG Mon Jul 14 11:06:55 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E444710656C8 for ; Mon, 14 Jul 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BE7628FC20 for ; Mon, 14 Jul 2008 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6EB6te4014362 for ; Mon, 14 Jul 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6EB6tM2014358 for freebsd-arch@FreeBSD.org; Mon, 14 Jul 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Jul 2008 11:06:55 GMT Message-Id: <200807141106.m6EB6tM2014358@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org 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, 14 Jul 2008 11:06:56 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 09:34:10 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D1E1065672; Tue, 15 Jul 2008 09:34:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA808FC18; Tue, 15 Jul 2008 09:34:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6F9Y22j063305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 12:34:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6F9Y2ju073518; Tue, 15 Jul 2008 12:34:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6F9Y2FX073517; Tue, 15 Jul 2008 12:34:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jul 2008 12:34:02 +0300 From: Kostik Belousov To: Stacey Son Message-ID: <20080715093402.GO17123@deviant.kiev.zoral.com.ua> References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> <487AD49F.6040304@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tlBB11+jzEStP2nB" Content-Disposition: inline In-Reply-To: <487AD49F.6040304@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua Cc: Andrew Gallatin , freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver 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, 15 Jul 2008 09:34:10 -0000 --tlBB11+jzEStP2nB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 13, 2008 at 11:22:55PM -0500, Stacey Son wrote: > Kostik Belousov wrote: > >Most likely, I miss some obvious reason there. But for me it looks > >like you do it in the reverse. The natural setup would be to require > >userspace to supply an allocated memory to the driver, and then the > >driver fills the memory with symbol table. This solves the problem of > >exhaustion of kernel address space. > > =20 >=20 > The snapshot of the consolidated symbol table is made when /dev/ksyms is= =20 > opened. The storage for the snapshot is allocated in the memory map of= =20 > the calling process. No kernel address space is used for the snapshot. Again, why this is done this way ? Why not creating snapshot when the user process issues ioctl that supplies neccessary usermode memory to the driver ? >=20 > A temporary buffer is allocated in kernel space in the read() handler=20 > (ksyms_read). Right now, for a read, it does two copies: one from=20 > user space to the temporary kernel space buffer and a second copy from=20 > the kernel space temp buffer and back out to user space. Ideally, it=20 > would be nice to do just one user space to user space copy directly in=20 > the kernel. >=20 > >As usual, when user-supplied region is too small, driver shall return > >both an error and new required size. It is understandable that the size > >is volatile and may be too small for the next call too. But, in fact, > >kernel symtable does not change too often, so I think even the one > >iteration mostly succeed. > > =20 >=20 > The reason the driver tries three times to create a valid snapshot is I= =20 > couldn't figure out a way (without creating a lock reversal) to=20 > temporarily keep modules from being loaded or unloaded while the=20 > snapshot is created. I agree that it should be able to create the=20 > snapshot on the first iteration in most cases. >=20 > BTW, you may have noticed the ksyms driver now uses your per-open file=20 > private data code which I like much better than using clone_create() for= =20 > per-descriptor storage. Does it work ? Do you have any suggestions for the KPI ? --tlBB11+jzEStP2nB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh8bwkACgkQC3+MBN1Mb4jKCACgk8JxGJf2CHd/JB31ouYKxw5J 7ikAoJtSodf1j2gW1I3xUqNRwA2UMLqO =2azh -----END PGP SIGNATURE----- --tlBB11+jzEStP2nB-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 13:11:53 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3972B1065670 for ; Tue, 15 Jul 2008 13:11:53 +0000 (UTC) (envelope-from sson@freebsd.org) Received: from www.son.org (son.org [199.239.233.23]) by mx1.freebsd.org (Postfix) with ESMTP id CCB748FC0A for ; Tue, 15 Jul 2008 13:11:52 +0000 (UTC) (envelope-from sson@freebsd.org) Received: from mactel.local (ppp-68-90-8-92.dsl.rcsntx.swbell.net [68.90.8.92]) (authenticated bits=0) by www.son.org (8.13.6.20060614/8.13.6) with ESMTP id m6FDBoPF026867; Tue, 15 Jul 2008 08:11:51 -0500 (CDT) Message-ID: <487CA2B4.7070604@freebsd.org> Date: Tue, 15 Jul 2008 08:14:28 -0500 From: Stacey Son User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008070703) MIME-Version: 1.0 To: Kostik Belousov References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> <487AD49F.6040304@freebsd.org> <20080715093402.GO17123@deviant.kiev.zoral.com.ua> In-Reply-To: <20080715093402.GO17123@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Gallatin , freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver 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, 15 Jul 2008 13:11:53 -0000 Kostik Belousov wrote: >> The snapshot of the consolidated symbol table is made when /dev/ksyms is >> opened. The storage for the snapshot is allocated in the memory map of >> the calling process. No kernel address space is used for the snapshot. >> > Again, why this is done this way ? Why not creating snapshot when the > user process issues ioctl that supplies neccessary usermode memory > to the driver ? > The main reason it is written as a pseudo driver is so it can be used with standard command-line utilities. For example, see the ksyms example in the dtrace manual (http://wikis.sun.com/display/DTrace/Structs+and+Unions). I guess it could still be possible to do in the way you are suggesting but it would require a special 'cat', or something, to allocate the user space buffer and then pass that in driver before it starts reading the symbol table. You could then pipe the output of the "special ksyms cat" to the actual command-line program you wanted to use. Of course, if you had to use a "special ksyms cat" then there would be no reason to make this a pseudo driver. You could simply make it a system call and eliminate a lot of code and calls into the kernel. >> BTW, you may have noticed the ksyms driver now uses your per-open file >> private data code which I like much better than using clone_create() for >> per-descriptor storage. >> > Does it work ? Do you have any suggestions for the KPI ? > Yes, it seems to work much better than the previous method (clone_create) but more testing is needed. I was having problems with the clone_create() method when I was running some testing code that would rapidly open /dev/ksyms. open() would fail. I am guessing there may be a race condition between when the device is cloned and actually open'ed. I'll let you know if I have some suggestions for the KPI. -stacey. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 13:18:11 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AA2C106564A; Tue, 15 Jul 2008 13:18:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id E68578FC20; Tue, 15 Jul 2008 13:18:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6FDI1FQ080666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 16:18:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6FDI1jY082764; Tue, 15 Jul 2008 16:18:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6FDI1jx082763; Tue, 15 Jul 2008 16:18:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jul 2008 16:18:01 +0300 From: Kostik Belousov To: Stacey Son Message-ID: <20080715131801.GS17123@deviant.kiev.zoral.com.ua> References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> <487AD49F.6040304@freebsd.org> <20080715093402.GO17123@deviant.kiev.zoral.com.ua> <487CA2B4.7070604@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kR01/VAbwQaE53Z3" Content-Disposition: inline In-Reply-To: <487CA2B4.7070604@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua Cc: Andrew Gallatin , freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver 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, 15 Jul 2008 13:18:11 -0000 --kR01/VAbwQaE53Z3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2008 at 08:14:28AM -0500, Stacey Son wrote: > Kostik Belousov wrote: > >>The snapshot of the consolidated symbol table is made when /dev/ksyms is > >>opened. The storage for the snapshot is allocated in the memory map of > >>the calling process. No kernel address space is used for the snapshot. > >> =20 > >Again, why this is done this way ? Why not creating snapshot when the > >user process issues ioctl that supplies neccessary usermode memory > >to the driver ? > > =20 >=20 > The main reason it is written as a pseudo driver is so it can be used=20 > with standard command-line utilities. For example, see the ksyms=20 > example in the dtrace manual=20 > (http://wikis.sun.com/display/DTrace/Structs+and+Unions). I guess it=20 > could still be possible to do in the way you are suggesting but it would= =20 > require a special 'cat', or something, to allocate the user space buffer= =20 > and then pass that in driver before it starts reading the symbol table. = =20 > You could then pipe the output of the "special ksyms cat" to the actual= =20 > command-line program you wanted to use. Of course, if you had to use= =20 > a "special ksyms cat" then there would be no reason to make this a=20 > pseudo driver. You could simply make it a system call and eliminate a= =20 > lot of code and calls into the kernel. Would dd bs=3D work as the "special cat" ? procfs' /proc/pid/map has the similar problem, and there was a procmap program in ports. I believe dd is enough. --kR01/VAbwQaE53Z3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh8o4gACgkQC3+MBN1Mb4gk6wCgudTjZWHagF5Xyr8kkJhDno0l iKAAoLZCuZpw2ZNArz/qAyNzHZeh6Ryg =10Cr -----END PGP SIGNATURE----- --kR01/VAbwQaE53Z3-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 15:53:29 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 940151065674; Tue, 15 Jul 2008 15:53:29 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFF18FC17; Tue, 15 Jul 2008 15:53:29 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id m6FFrMLR010770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 11:53:28 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu m6FFrMLR010770 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1216137208; bh=r/XIzLxEc7YxCQ8bLSOrtKjSJLtS14Fgmjui0NJkbO8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gVXtUt2I0lHe hevOCvlccF1kok9E/PVlQOgOZfkYigEDxBNfHRRatkfmqBnngC+lE9LCCrq3f61uVEe +rkrRK5cilr8qW3iUvBcESeaNkjguE/xZmthbVutiuDpW9gYcjj2+xA3wgfUAJ4r7xP bN/aaBa3sg8zMMNmnjs+awxLY= Message-ID: <487CC7EC.5060100@cs.duke.edu> Date: Tue, 15 Jul 2008 11:53:16 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Stacey Son References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> <487AD49F.6040304@freebsd.org> <20080715093402.GO17123@deviant.kiev.zoral.com.ua> <487CA2B4.7070604@freebsd.org> In-Reply-To: <487CA2B4.7070604@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver 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, 15 Jul 2008 15:53:29 -0000 Stacey Son wrote: > The main reason it is written as a pseudo driver is so it can be used > with standard command-line utilities. For example, see the ksyms Ah, now everything is perfectly clear to me. Your method is very clever indeed. Just out of curiosity, how much memory will the entire symbol + strings table require? How often do typical consumers (like dtrace) request them? Drew From owner-freebsd-arch@FreeBSD.ORG Tue Jul 15 18:25:37 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83151065670 for ; Tue, 15 Jul 2008 18:25:37 +0000 (UTC) (envelope-from sson@freebsd.org) Received: from www.son.org (son.org [199.239.233.23]) by mx1.freebsd.org (Postfix) with ESMTP id AE8448FC0C for ; Tue, 15 Jul 2008 18:25:37 +0000 (UTC) (envelope-from sson@freebsd.org) Received: from mactel.local (ppp-68-90-8-92.dsl.rcsntx.swbell.net [68.90.8.92]) (authenticated bits=0) by www.son.org (8.13.6.20060614/8.13.6) with ESMTP id m6FIPahY009060; Tue, 15 Jul 2008 13:25:36 -0500 (CDT) Message-ID: <487CEC3E.3060204@freebsd.org> Date: Tue, 15 Jul 2008 13:28:14 -0500 From: Stacey Son User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008070703) MIME-Version: 1.0 To: Andrew Gallatin References: <4875A5D2.8030902@freebsd.org> <20080711155232.A96384@grasshopper.cs.duke.edu> <48780661.5050002@freebsd.org> <20080712045837.GD17123@deviant.kiev.zoral.com.ua> <487AD49F.6040304@freebsd.org> <20080715093402.GO17123@deviant.kiev.zoral.com.ua> <487CA2B4.7070604@freebsd.org> <487CC7EC.5060100@cs.duke.edu> In-Reply-To: <487CC7EC.5060100@cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-arch@freebsd.org Subject: Re: ksyms pseudo driver 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, 15 Jul 2008 18:25:38 -0000 Andrew Gallatin wrote: > Ah, now everything is perfectly clear to me. Your method is > very clever indeed. > > Just out of curiosity, how much memory will the entire symbol > + strings table require? How often do typical consumers (like dtrace) > request them? On an AMD64 "Generic" kernel with only the ksyms module loaded it is 1523847 bytes. lockstat(1M) will open and read /dev/ksyms once each time it is invoked. For dtrace, it depends on the script but there shouldn't be any reason why it reads it more than once as well. -stacey. From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 03:07:08 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 334C71065674 for ; Sat, 19 Jul 2008 03:07:08 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17BD88FC1B for ; Sat, 19 Jul 2008 03:07:08 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id j4so256428wah.3 for ; Fri, 18 Jul 2008 20:07:07 -0700 (PDT) Received: by 10.115.60.1 with SMTP id n1mr670565wak.179.1216435336625; Fri, 18 Jul 2008 19:42:16 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id v38sm3540207wah.14.2008.07.18.19.42.14 (version=SSLv3 cipher=RC4-MD5); Fri, 18 Jul 2008 19:42:15 -0700 (PDT) Date: Fri, 18 Jul 2008 16:41:58 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: <20080718163231.B954@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@freebsd.org, ivmaykov@gmail.com Subject: witness performance improvements 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: Sat, 19 Jul 2008 03:07:08 -0000 Hello, I have a patch that improves witness performance available at: http://people.freebsd.org/~jeff/witness.diff This improvement comes at the cost of some significant space overhead. It changes the witness graph from a linked tree to a matrix based approach. Relationships can be quickly resolved with a table lookup. The table size is WITNESS_COUNT^2, or 1MB with the current count of 1024. This patch also makes struct witness objects persistent even after the last lock using this name has been removed. This is helpful for short lived objects which may be created frequently. To reduce lock contention on SMP witness_checkorder() now runs without the w_mtx when there are no lock violations. I also cache a lock_list_entry in each thread as allocating these requires the w_mtx. The entry is disposed of at thread_exit(). There is also a new sysctl that produces dot output which graphs lock order relationships with the graphviz program. Most of this work was done by Ilya Maykov while he was at Isilon systems. The locking work and some cleanup/porting/refinement was done by me on behalf of Nokia. The performance improvement can be significant. It is only on the order of 10-20% for buildkernel but on a packet forwarding test at nokia it sped things up by 5x putting a witness enabled kernel within about 50% of the performance of a kernel without. I believe buildworld isn't helped as much because forking and exiting a lot would then contend on the witness lock. I'm mostly interested in hearing what people have to say about the space bloat. I believe it is in a commit ready state. Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 07:42:57 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D7F71065674 for ; Sat, 19 Jul 2008 07:42:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 200768FC18 for ; Sat, 19 Jul 2008 07:42:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6406F23EB; Sat, 19 Jul 2008 00:32:13 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D91AC2D604E; Sat, 19 Jul 2008 00:32:12 -0700 (PDT) Message-ID: <48819885.7040901@elischer.org> Date: Sat, 19 Jul 2008 00:32:21 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jeff Roberson References: <20080718163231.B954@desktop> In-Reply-To: <20080718163231.B954@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, arch@freebsd.org, ivmaykov@gmail.com Subject: Re: witness performance improvements 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: Sat, 19 Jul 2008 07:42:57 -0000 Jeff Roberson wrote: > Hello, > > I have a patch that improves witness performance available at: > > http://people.freebsd.org/~jeff/witness.diff > > This improvement comes at the cost of some significant space overhead. > It changes the witness graph from a linked tree to a matrix based > approach. Relationships can be quickly resolved with a table lookup. > The table size is WITNESS_COUNT^2, or 1MB with the current count of 1024. > > This patch also makes struct witness objects persistent even after the > last lock using this name has been removed. This is helpful for short > lived objects which may be created frequently. > > To reduce lock contention on SMP witness_checkorder() now runs without > the w_mtx when there are no lock violations. I also cache a > lock_list_entry in each thread as allocating these requires the w_mtx. > The entry is disposed of at thread_exit(). > > There is also a new sysctl that produces dot output which graphs lock > order relationships with the graphviz program. > cool... got sample output? > Most of this work was done by Ilya Maykov while he was at Isilon > systems. The locking work and some cleanup/porting/refinement was done > by me on behalf of Nokia. > > The performance improvement can be significant. It is only on the order > of 10-20% for buildkernel but on a packet forwarding test at nokia it > sped things up by 5x putting a witness enabled kernel within about 50% > of the performance of a kernel without. I believe buildworld isn't > helped as much because forking and exiting a lot would then contend on > the witness lock. > > I'm mostly interested in hearing what people have to say about the space > bloat. I believe it is in a commit ready state. Since witness is not usually on production systems, I don't see a problem with giving it 1 MB. kjfnb7 > > Thanks, > Jeff > _______________________________________________ > 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 Sat Jul 19 12:55:09 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B89106566B for ; Sat, 19 Jul 2008 12:55:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6F68FC15 for ; Sat, 19 Jul 2008 12:55:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so424117fgb.35 for ; Sat, 19 Jul 2008 05:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=fwGsCg5xZShNq7OUS6rFwy9bg0EiGcmRe8KjYlBAums=; b=ZOxYx3ybX+Zdx57MT61Zdi82h0nW2S1MaWE2yvcueD1nRfArh6BxJTgEoMQF+3Kz3C 7gZ9E+Bi6UhQzrVyL6YnSQJcj1kC0DoLaB50SEgbe3Rtr6VKjA1HpPV8cf9S+UhPl5Xc Z91GPeSUsncaiI5JOBi3HE+mG2LIb0ZQ911Rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=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=YDb0a50ATJNeE943p/V+qhhR6tzqz4ya3LylEX5gkS9WFbOo/oBdErIV2vs0Ihcofw fNi+OQX3I4AOfupceHDlQ9KtWNsEeABxGRLNlFYxSxNyQY59Eu+eaFgaoixTXYzjfKYm l/fmC801mzcZUpWdvFMVW5BjU42DIsUgvbWFw= Received: by 10.86.79.19 with SMTP id c19mr1983189fgb.5.1216470357910; Sat, 19 Jul 2008 05:25:57 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Sat, 19 Jul 2008 05:25:57 -0700 (PDT) Message-ID: <3bbf2fe10807190525y65facf80uad2a974619198186@mail.gmail.com> Date: Sat, 19 Jul 2008 14:25:57 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Jeff Roberson" In-Reply-To: <20080718163231.B954@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080718163231.B954@desktop> X-Google-Sender-Auth: beeac40afbaf3620 Cc: arch@freebsd.org, ivmaykov@gmail.com Subject: Re: witness performance improvements 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: Sat, 19 Jul 2008 12:55:09 -0000 2008/7/19, Jeff Roberson : > Hello, > > I have a patch that improves witness performance available at: > > http://people.freebsd.org/~jeff/witness.diff > > This improvement comes at the cost of some significant space overhead. It > changes the witness graph from a linked tree to a matrix based approach. > Relationships can be quickly resolved with a table lookup. The table size > is WITNESS_COUNT^2, or 1MB with the current count of 1024. > > This patch also makes struct witness objects persistent even after the last > lock using this name has been removed. This is helpful for short lived > objects which may be created frequently. > > To reduce lock contention on SMP witness_checkorder() now runs without the > w_mtx when there are no lock violations. I also cache a lock_list_entry in > each thread as allocating these requires the w_mtx. The entry is disposed > of at thread_exit(). > > There is also a new sysctl that produces dot output which graphs lock order > relationships with the graphviz program. As I alredy said, I don't like this. I mostly prefer the current approach (comma separated stuff) that one can shape as its need. If you also think there are some informations the current sysctl doesn't export and it should we could fix it, but IMHO we should axe this part of the patch (I have still to look at this patch, but I remind in the Isilon's version it was a good amount of structures and modifies just to handle that part). > Most of this work was done by Ilya Maykov while he was at Isilon systems. > The locking work and some cleanup/porting/refinement was done by me on > behalf of Nokia. > > The performance improvement can be significant. It is only on the order of > 10-20% for buildkernel but on a packet forwarding test at nokia it sped > things up by 5x putting a witness enabled kernel within about 50% of the > performance of a kernel without. I believe buildworld isn't helped as much > because forking and exiting a lot would then contend on the witness lock. > > I'm mostly interested in hearing what people have to say about the space > bloat. I believe it is in a commit ready state. This should not be a big problem, it is a debugging kernel after all if it has WITNESS. I hope I will have more time for a detailed revision in the day. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 14:12:38 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D17A106566B for ; Sat, 19 Jul 2008 14:12:38 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.ipv6.0x20.net [IPv6:2001:aa8:fffb::3]) by mx1.freebsd.org (Postfix) with ESMTP id 987AD8FC19 for ; Sat, 19 Jul 2008 14:12:37 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id 2ACD53A682; Sat, 19 Jul 2008 16:12:36 +0200 (CEST) Date: Sat, 19 Jul 2008 16:12:36 +0200 From: Lars Engels To: Jeff Roberson Message-ID: <20080719141236.GF56464@e.0x20.net> References: <20080718163231.B954@desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: <20080718163231.B954@desktop> X-Editor: VIM - Vi IMproved 7.1 X-Operation-System: FreeBSD 5.5-RELEASE-p19 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: arch@freebsd.org Subject: Re: witness performance improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lars Engels List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 14:12:38 -0000 --7iMSBzlTiPOCCT2k Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 18, 2008 at 04:41:58PM -1000, Jeff Roberson wrote: > Hello, >=20 > I have a patch that improves witness performance available at: >=20 > http://people.freebsd.org/~jeff/witness.diff >=20 > This improvement comes at the cost of some significant space overhead. > It changes the witness graph from a linked tree to a matrix based > approach. Relationships can be quickly resolved with a table lookup. > The table size is WITNESS_COUNT^2, or 1MB with the current count of > 1024. >=20 > This patch also makes struct witness objects persistent even after the > last lock using this name has been removed. This is helpful for short > lived objects which may be created frequently. >=20 > To reduce lock contention on SMP witness_checkorder() now runs without > the w_mtx when there are no lock violations. I also cache a > lock_list_entry in each thread as allocating these requires the w_mtx. > The entry is disposed of at thread_exit(). >=20 > There is also a new sysctl that produces dot output which graphs lock > order relationships with the graphviz program. >=20 > Most of this work was done by Ilya Maykov while he was at Isilon > systems. The locking work and some cleanup/porting/refinement was done > by me on behalf of Nokia. >=20 > The performance improvement can be significant. It is only on the > order of 10-20% for buildkernel but on a packet forwarding test at > nokia it sped things up by 5x putting a witness enabled kernel within > about 50% of the performance of a kernel without. I believe > buildworld isn't helped as much because forking and exiting a lot > would then contend on the witness lock. >=20 > I'm mostly interested in hearing what people have to say about the > space bloat. I believe it is in a commit ready state. >=20 > Thanks, > Jeff The speed improvement is significant here (Core Duo Machine). The kernel build time went from ~8:30 min to 5:30 min.=20 But when I run sysctl -a the kernel panics. kgdb output: Unread portion of the kernel message buffer: panic: Assertion mcount =3D=3D fcount failed at /usr/src/sys/kern/subr_witness.c:2882 cpuid =3D 1 KDB: enter: panic panic: from debugger cpuid =3D 1 KDB: stack backtrace: Physical memory: 1002 MB Dumping 68 MB: 53 37 21 5 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0476c69 in db_fncall (dummy1=3D-1061959744, dummy2=3D0, dummy3=3D3, dummy4=3D0xe54ce8ec "") at /usr/src/sys/ddb/db_command.c:516 #2 0xc0477218 in db_command (last_cmdp=3D0xc099a9b0, cmd_table=3D0x0, dopager=3D1) at /usr/src/sys/ddb/db_command.c:413 #3 0xc047734a in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #4 0xc0478b3d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.c:228 #5 0xc0618d56 in kdb_trap (type=3D3, code=3D0, tf=3D0xe54cea94) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xc087ec36 in trap (frame=3D0xe54cea94) at /usr/src/sys/i386/i386/trap.c:683 #7 0xc08634bb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #8 0xc0618eda in kdb_enter (why=3D0xc08dc49c "panic", msg=3D0xc08dc49c "panic") at cpufunc.h:60 #9 0xc05ebe9c in panic (fmt=3D0xc08d72ed "Assertion %s failed at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:556 #10 0xc062bf62 in sysctl_debug_witness_cyclegraph (oidp=3D0xc096bec0, arg1=3D0x0, arg2=3D0, req=3D0xe54ceba4) at /usr/src/sys/kern/subr_witness.c:2882 #11 0xc05f59d7 in sysctl_root (oidp=3DVariable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1325 #12 0xc05f5b05 in userland_sysctl (td=3D0xc49c08c0, name=3D0xe54cec10, namelen=3D3, old=3D0x0, oldlenp=3D0xbfbfd9b0, inkernel=3D0, new=3D0x0, newl= en=3D0, retval=3D0xe54cec70, flags=3D0) at /usr/src/sys/kern/kern_sysctl.c:1420 #13 0xc05f5f4c in __sysctl (td=3D0xc49c08c0, uap=3D0xe54cecf8) at /usr/src/sys/kern/kern_sysctl.c:1355 #14 0xc087e3b3 in syscall (frame=3D0xe54ced38) at /usr/src/sys/i386/i386/trap.c:1081 #15 0xc0863520 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) The kernel sources are one week old. --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiB9lQACgkQKc512sD3afh1XgCfUuP0qvBLuE+GYN1lF3iEdkxU wmYAoIP2aIDjccTcVViLbY09WUWZsiaL =kD/c -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 17:59:30 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0221106567B for ; Sat, 19 Jul 2008 17:59:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id AF4D68FC1A for ; Sat, 19 Jul 2008 17:59:30 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.102] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K4900LZ1LZ53T80@asmtp022.mac.com> for arch@freebsd.org; Sat, 19 Jul 2008 10:59:30 -0700 (PDT) Sender: xcllnt@mac.com Message-id: <34889018-8358-46AC-897E-32767FB84E14@mac.com> From: Marcel Moolenaar To: FreeBSD Arch Date: Sat, 19 Jul 2008 10:59:29 -0700 X-Mailer: Apple Mail (2.928.1) Cc: Subject: RFC: cross-libkvm/libthread_db/proc_service 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: Sat, 19 Jul 2008 17:59:31 -0000 All, We have a couple of interfaces/APIs that can't be used cross-platform. Take for example libkvm. On a 32-bit platform, we can't typically use libkvm on a 64-kernel, because the libkvm interface uses u_long for the target address, which on 32-bit platforms is 32 bits wide. Likewise, libthread_db and proc_service are designed for native use only and need API tweaks to work in a cross-environment. Both use psaddr_t to represent a target address, which is defined as a void* in . I'd like to change those interfaces/APIs to allow them to be used in a cross-platform debugging environment. Basically, this means that a target address will have to be defined as a uint64_t. Other datatypes may also need to be retyped. For libkvm in particular I don't want to redefine struct kinfo_proc, struct nlist, etc. While it could be useful in a hybrid 32/64-bit environment, the effect of such changes have too high a chance to trickle down various other components/interfaces. Thus, for libkvm the focus is on kvm_read() and kvm_write(). Suggested plan of attack: o add kvm_xread() and kvm_xwrite() to the libkvm API to minimize the overall impact. The new functions operate on a 64-bit target address (psaddr_t). o change psaddr_t from a void* to a 64-bit integral (sys/procfs.h) This affects proc_service and libthread_db. And consequently our threading support in GDB. Comments/thoughts? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 18:42:47 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3148106566B for ; Sat, 19 Jul 2008 18:42:47 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 880DD8FC15 for ; Sat, 19 Jul 2008 18:42:47 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.102] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K49004QONZ8D170@asmtp011.mac.com> for arch@freebsd.org; Sat, 19 Jul 2008 11:42:47 -0700 (PDT) Sender: xcllnt@mac.com Message-id: <6EA6C2B0-EF45-4A65-A455-65700BA6B024@mac.com> From: Marcel Moolenaar To: Kostik Belousov In-reply-to: <20080719183725.GM17123@deviant.kiev.zoral.com.ua> Date: Sat, 19 Jul 2008 11:42:44 -0700 References: <34889018-8358-46AC-897E-32767FB84E14@mac.com> <20080719183725.GM17123@deviant.kiev.zoral.com.ua> X-Mailer: Apple Mail (2.928.1) Cc: FreeBSD Arch Subject: Re: RFC: cross-libkvm/libthread_db/proc_service 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: Sat, 19 Jul 2008 18:42:47 -0000 On Jul 19, 2008, at 11:37 AM, Kostik Belousov wrote: > On Sat, Jul 19, 2008 at 10:59:29AM -0700, Marcel Moolenaar wrote: >> All, >> >> We have a couple of interfaces/APIs that can't be used cross- >> platform. >> >> Take for example libkvm. On a 32-bit platform, we can't typically use >> libkvm on a 64-kernel, because the libkvm interface uses u_long for >> the target address, which on 32-bit platforms is 32 bits wide. >> >> Likewise, libthread_db and proc_service are designed for native use >> only and need API tweaks to work in a cross-environment. Both use >> psaddr_t to represent a target address, which is defined as a void* >> in . >> >> I'd like to change those interfaces/APIs to allow them to be used in >> a cross-platform debugging environment. Basically, this means that a >> target address will have to be defined as a uint64_t. Other datatypes >> may also need to be retyped. >> >> For libkvm in particular I don't want to redefine struct kinfo_proc, >> struct nlist, etc. While it could be useful in a hybrid 32/64-bit >> environment, the effect of such changes have too high a chance to >> trickle down various other components/interfaces. Thus, for libkvm >> the focus is on kvm_read() and kvm_write(). >> >> Suggested plan of attack: >> o add kvm_xread() and kvm_xwrite() to the libkvm API to minimize >> the overall impact. The new functions operate on a 64-bit target >> address (psaddr_t). >> o change psaddr_t from a void* to a 64-bit integral (sys/procfs.h) >> This affects proc_service and libthread_db. And consequently our >> threading support in GDB. >> >> Comments/thoughts? > > I do not object to the idea, but thing to consider is the backward > compatibility. In other words, how much harder would it be to run, > e.g., an RELENG_7 jail on the current kernel after the change ? The impact on the kernel is exactly nil. psaddr_t is not used by the kernel or its interfaces. It's only used for debug related functionality. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 18:48:13 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A83BC1065679 for ; Sat, 19 Jul 2008 18:48:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 28E3A8FC16 for ; Sat, 19 Jul 2008 18:48:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6JIbPm4015401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2008 21:37:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m6JIbPKU040733; Sat, 19 Jul 2008 21:37:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6JIbPeE040732; Sat, 19 Jul 2008 21:37:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Jul 2008 21:37:25 +0300 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20080719183725.GM17123@deviant.kiev.zoral.com.ua> References: <34889018-8358-46AC-897E-32767FB84E14@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Et2Bf2pEd/Zt/VCU" Content-Disposition: inline In-Reply-To: <34889018-8358-46AC-897E-32767FB84E14@mac.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Arch Subject: Re: RFC: cross-libkvm/libthread_db/proc_service 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: Sat, 19 Jul 2008 18:48:13 -0000 --Et2Bf2pEd/Zt/VCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 19, 2008 at 10:59:29AM -0700, Marcel Moolenaar wrote: > All, >=20 > We have a couple of interfaces/APIs that can't be used cross-platform. >=20 > Take for example libkvm. On a 32-bit platform, we can't typically use > libkvm on a 64-kernel, because the libkvm interface uses u_long for > the target address, which on 32-bit platforms is 32 bits wide. >=20 > Likewise, libthread_db and proc_service are designed for native use > only and need API tweaks to work in a cross-environment. Both use > psaddr_t to represent a target address, which is defined as a void* > in . >=20 > I'd like to change those interfaces/APIs to allow them to be used in > a cross-platform debugging environment. Basically, this means that a > target address will have to be defined as a uint64_t. Other datatypes > may also need to be retyped. >=20 > For libkvm in particular I don't want to redefine struct kinfo_proc, > struct nlist, etc. While it could be useful in a hybrid 32/64-bit > environment, the effect of such changes have too high a chance to > trickle down various other components/interfaces. Thus, for libkvm > the focus is on kvm_read() and kvm_write(). >=20 > Suggested plan of attack: > o add kvm_xread() and kvm_xwrite() to the libkvm API to minimize > the overall impact. The new functions operate on a 64-bit target > address (psaddr_t). > o change psaddr_t from a void* to a 64-bit integral (sys/procfs.h) > This affects proc_service and libthread_db. And consequently our > threading support in GDB. >=20 > Comments/thoughts? I do not object to the idea, but thing to consider is the backward compatibility. In other words, how much harder would it be to run, e.g., an RELENG_7 jail on the current kernel after the change ? --Et2Bf2pEd/Zt/VCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiCNGUACgkQC3+MBN1Mb4iFuACgmYvOYT3zq4V8tg99FT3pGeE6 XwgAoK58mDcyDTBJa+aPVIjXN6wVdN+q =1ELf -----END PGP SIGNATURE----- --Et2Bf2pEd/Zt/VCU--