Date: Sat, 16 Feb 2002 13:47:09 -0800 From: Alfred Perlstein <bright@mu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG, jhb@FreeBSD.ORG, peter@wemm.org, jake@locore.ca Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday() and copyout(). Is copyout() MPSAFE on non-i386 archs? ) Message-ID: <20020216214709.GA12136@elvis.mu.org> In-Reply-To: <200202162033.g1GKXOf13029@apollo.backplane.com> References: <6988.1013844797@critter.freebsd.dk> <200202162033.g1GKXOf13029@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [020216 12:33] wrote: > :Make sure to run something which abuses gettimeofday() for select, > :maybe netscape or some other multi-threaded nightmare. > : > :-- > :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > :phk@FreeBSD.ORG | TCP/IP since RFC 956 > > I can run some backplane database stuff, that's fairly select/gettimeofday > intensive. > > This is what I am running right now (see below). When combined with the > /bin/ps change I just comitted and gdb'ing -k kernel.debug /dev/mem to > look at where the process is getting stuck when running two of them on an > SMP system. It looks like it is mainly getting stuck in the > mtx_lock(&Giant) call around the crfree() call in trap.c (the syscall > code). > > Does anyone mind if I fix the credential code? Locking Giant for > every syscall doesn't make any sense, nor does calling FREE() inside > crfree() or embedding an internal mutex in the ucred. It can all > be done with mtxpool-protected credentials and a ucred freelist. It > would take me less then an hour to fix it but I don't want to step on > any toes if someone else is already on it. Go ahead with using mutex pools for creds, I thought I'd done it already but it looks like I only got to struct file and struct uidinfo. :) I do sort of think that keeping your own cred freelist is probably a bad idea especially with what Jeff R has coming down the pipe for us. But we can take that out later if something better comes along. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020216214709.GA12136>