Re: inheriting the lwp private area

2011-03-23 Thread Matt Thomas
On Mar 22, 2011, at 8:51 PM, Antti Kantee wrote: Hi, On Julio's request I was looking at the now-failing tests and resulting hanging processes. Basically at least on i386 the failures are a result of fork() + setcontext() (plus some voodoo) after which calling pthread_mutex_lock() with

Re: libquota proposal

2011-03-23 Thread Manuel Bouyer
On Wed, Mar 23, 2011 at 03:44:53AM +, David Holland wrote: On Tue, Mar 22, 2011 at 05:41:52PM +0100, Manuel Bouyer wrote: | (also, edquota and repquota seem fs-independent to me...) | | no, they're not: they can directly the quota1 file specified in the | fstab if

Re: libquota proposal

2011-03-23 Thread Manuel Bouyer
On Wed, Mar 23, 2011 at 03:45:45AM +, David Holland wrote: On Tue, Mar 22, 2011 at 03:21:22PM +0100, Manuel Bouyer wrote: That's a bug, or more accurately legacy behavior that doesn't need to be supported. of course it's not nice. But we're talking about existing code calling

Re: Decomposing vfs_subr.c

2011-03-23 Thread Andrew Doran
On Wed, Mar 23, 2011 at 04:07:29AM +, Mindaugas Rasiukevicius wrote: I would like to split-off parts of vfs_subr.c into vfs_node.c * and vfs_mount.c modules. Decomposing should hopefully bring some better abstraction, as well as make it easier to work with VFS subsystem. Any

Re: inheriting the lwp private area

2011-03-23 Thread Andrew Doran
On Wed, Mar 23, 2011 at 12:53:24AM -0700, Matt Thomas wrote: On Mar 22, 2011, at 8:51 PM, Antti Kantee wrote: Hi, On Julio's request I was looking at the now-failing tests and resulting hanging processes. Basically at least on i386 the failures are a result of fork() +

Re: Decomposing vfs_subr.c

2011-03-23 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: I would like to split-off parts of vfs_subr.c into vfs_node.c * and vfs_mount.c modules. Decomposing should hopefully bring some better abstraction, as well as make it easier to work with VFS subsystem. Any objections? Sounds good to me. Some

Re: inheriting the lwp private area

2011-03-23 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: You mean l-l_private should be copied on fork? Absolutely. For native fork I agree, but that's probably not the right thing to do if FORK_SHARESIGS or whatever it's called (i.e. clone()ing off a Linux-style thread). (Some day I hope we can emulate

Re: inheriting the lwp private area

2011-03-23 Thread Andrew Doran
On Wed, Mar 23, 2011 at 02:19:53PM +, Mindaugas Rasiukevicius wrote: Andrew Doran a...@netbsd.org wrote: You mean l-l_private should be copied on fork? Absolutely. For native fork I agree, but that's probably not the right thing to do if FORK_SHARESIGS or whatever it's called

Re: libquota proposal

2011-03-23 Thread David Holland
(more context restored) On Wed, Mar 23, 2011 at 09:51:48AM +0100, Manuel Bouyer wrote: (also, edquota and repquota seem fs-independent to me...) no, they're not: they can directly the quota1 file specified in the fstab if quotactl fails or the filesystem is not mounted. That's a bug,

Re: libquota proposal

2011-03-23 Thread David Holland
On Wed, Mar 23, 2011 at 09:50:16AM +0100, Manuel Bouyer wrote: On Wed, Mar 23, 2011 at 03:44:53AM +, David Holland wrote: On Tue, Mar 22, 2011 at 05:41:52PM +0100, Manuel Bouyer wrote: | (also, edquota and repquota seem fs-independent to me...) | | no, they're not:

Re: libquota proposal

2011-03-23 Thread Manuel Bouyer
On Wed, Mar 23, 2011 at 03:45:34PM +, David Holland wrote: No, it doesn't. Even before you touched anything, they were only scribbling directly as a fallback if the kernel operations failed. The kernel operations should not fail in any case where scribbling directly makes

Re: libquota proposal

2011-03-23 Thread Manuel Bouyer
On Wed, Mar 23, 2011 at 03:43:10PM +, David Holland wrote: (more context restored) On Wed, Mar 23, 2011 at 09:51:48AM +0100, Manuel Bouyer wrote: (also, edquota and repquota seem fs-independent to me...) no, they're not: they can directly the quota1 file specified in the fstab

Re: Decomposing vfs_subr.c

2011-03-23 Thread David Holland
On Wed, Mar 23, 2011 at 02:18:55PM +, Mindaugas Rasiukevicius wrote: I would like to split-off parts of vfs_subr.c into vfs_node.c * and vfs_mount.c modules. Decomposing should hopefully bring some better abstraction, as well as make it easier to work with VFS subsystem.

Re: high sys time, very very slow builds on new 24-core system

2011-03-23 Thread Eduardo Horvath
On Wed, 23 Mar 2011, Thor Lancelot Simon wrote: I have a new machine with 24 2Ghz Opteron cores. It has 32GB of RAM. Building with sources on a fast SSD (preloaded into the page cache before the build using tar /dev/null) and obj, dest, and rel dirs on tmpfs, system builds are

Re: Decomposing vfs_subr.c

2011-03-23 Thread Mindaugas Rasiukevicius
David Holland dholland-t...@netbsd.org wrote: - I think it should be vfs_vnode.c? OK, unless somebody will come up with a better name. Since AIUI from chat this is going to contain the vnode lifecycle and code and not e.g. stuff like vn_lock, I think I'd prefer vfs_vncache.c.

Re: Status and future of 3rd party ABI compatibility layer

2011-03-23 Thread Andrew Doran
Hi Joerg. On Wed, Mar 23, 2011 at 04:06:07PM +0100, Joerg Sonnenberger wrote: Hi all, the following is what I consider as summary of the thread. Use cases mentioned for or considered simple enough: - Linux - FreeBSD - OSF1 - Ultrix - SVR/SVR4 Incomplete, broken and of questionable

Re: high sys time, very very slow builds on new 24-core system

2011-03-23 Thread Jukka Ruohonen
On Wed, Mar 23, 2011 at 05:24:12PM -0400, Thor Lancelot Simon wrote: All cores spend well over 50% time in 'sys', even when all or almost all are running cc1 processes. The kernel is amd64 -current GENERIC from about 1 week ago -- no DIAGNOSTIC, DEBUG, KMEMSTATS, LOCKDEBUG, etc. Does