From owner-freebsd-arch Sun Feb 17 16:58:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 6932D37B404; Sun, 17 Feb 2002 16:58:07 -0800 (PST) Received: from pool0152.cvx21-bradley.dialup.earthlink.net ([209.179.192.152] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16cc83-0003j1-00; Sun, 17 Feb 2002 16:58:03 -0800 Message-ID: <3C705190.8B56A024@mindspring.com> Date: Sun, 17 Feb 2002 16:57:52 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Poul-Henning Kamp , Julian Elischer , Alfred Perlstein , 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? ) References: <5405.1013975811@critter.freebsd.dk> <200202172011.g1HKBsv88526@apollo.backplane.com> <3C7049A4.15412853@mindspring.com> <200202180030.g1I0UU309210@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > I'm just going to point something out here, and that is my proposed > system call fully supports the kernel saying, in effect, 'I don't want > you accessing this particular parameter from shared memory, use the > old way of doing it'. > > For the vast majority of processes in a system this is a perfectly > reasonable response. The shared memory feature would only need to be > enabled for those few processes, like web servers, databases, and > big threaded programs that really need it. > > So we can afford to waste some memory for the few processes that actually > need the feature as long as we don't waste any for the processes that > don't. When I was talking about the 4k/8k per process KVA mapping costs, I was not really concerned with the per process costs, I was merely documenting them, in case someone else was concerned. Personally, I think the number of clients goes up significantly faster than the number of processes or threads; obviously this would not be true if there were a thread per client, but I think that people who code that way will never beat my numbers on total clients per host, so I don't care about them anyway, since they are already shooting themselves before they even have a chance to enter the race. So actually, I would prefer that the call succeed always, and that the failure be fatal. The only reason to maintain support for system-call based access to the data is for legacy applications, IMO. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message