From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 30 01:29:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAA8216A4B3 for ; Tue, 30 Sep 2003 01:29:09 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB29644022 for ; Tue, 30 Sep 2003 01:29:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc1ac.dialup.mindspring.com ([209.86.5.76] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A4FsT-0007lY-00; Tue, 30 Sep 2003 01:29:02 -0700 Message-ID: <3F793E9E.4164593F@mindspring.com> Date: Tue, 30 Sep 2003 01:28:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <16244.53594.942762.784390@canoe.dclg.ca> <3F759589.9070700@mindspring.com> <20030929154741.GB520@garage.freebsd.pl> <20030929191258.GC520@garage.freebsd.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a499c1d3e69414d6d2afbf0d49792343c6a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: earthman Subject: Re: user malloc from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 08:29:09 -0000 Pawel Jakub Dawidek wrote: > On Mon, Sep 29, 2003 at 06:56:13PM +0300, Peter Pentchev wrote: > +> I mean, won't the application's memory manager attempt to allocate the > +> next chunk of memory right over the region that you have stolen with > +> this brk(2) invocation? Thus, when the application tries to write into > +> its newly-allocated memory, it will overwrite the data that the kernel > +> has placed there, and any attempt to access the kernel's data later will > +> fail in wonderfully unpredictable ways :) > > I'm not sure if newly allocated memory will overwrite memory allocated > in kernel, but for sure process is able to write to this memory. > > Sometime ago I proposed model which will allow to remove all copyin(9) > calls and many copyout(9), but I'm not so skilled in VM to implement it. You probably need two pages; one R/O in user space and R/W in kernel space, and one R/W in both user and kernel space. The copyin() elimination would use the R/W page. Frankly, I have to say that you aren't saving much by eliminating copyin() this way, and most of your overhead is going to be data copies with pointers, and it doesn't really matter where you get the pointers into the kernel, the bummer is going to be copying around the data pointed to by the pointers. For the copyout, you'd probably get a rather larger benefit if you could implement getpid(), getuid(), getgid(), getppid(), and so on, in user space entirely, just by referencing the common read-only page. You could probably also benefit significantly by deobfuscating the timer code and using a flip-flop timer and externalizing the calibration information in a single globally read-only page (PG_G, PG_U, R/O mapping one place, kernel-only R/W mapping another), and then using it to implement a zero system call gettimeofday() operation (there's really no need to have a huge list of timers, if updates are effectively atomic at the clock interrupt, and you use a flip-flop pointer to only two contexts instead of a huge number of them). Specifically, you could find yourself with a huge performance improvement in anything that has to log in the Apache/SQUID styles, which require a *lot* of logging, which would mean a *lot* of system calls. You could also use a knote for this, which is only returned when other knote's are returned, and not otherwise, but that would be a lot less friendly to third party source code that was not specifically adulterated for FreeBSD. -- Terry