From owner-freebsd-hackers Thu Dec 6 7:33:41 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id D43B937B417 for ; Thu, 6 Dec 2001 07:33:37 -0800 (PST) Received: from dialup-209.245.132.144.dial1.sanjose1.level3.net ([209.245.132.144] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16C0Wm-0007Zb-00; Thu, 06 Dec 2001 07:33:36 -0800 Message-ID: <3C0F8FD6.689935C1@mindspring.com> Date: Thu, 06 Dec 2001 07:33:42 -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: Jonathan Lemon Cc: hackers@freebsd.org Subject: Re: Can TCP changes be put in RELENG_4? References: <200112061441.fB6Efw650278@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jonathan Lemon wrote: > > In article you write: > >Really, it boils down to the allocation systems needing rewrite, > >and (painful as this is to say) a move away from type stable > >memory, to permit reuse, rather than static purposing of large > >blocks: static purposing is the primary reason a general turning > >can not be near optimal for a lot of applications. > > Okay, this I can agree with. But I don't have the time or inclination > to write a new memory allocator. Did you have something in mind? I have a modification of the zone allocator which is much better at not wasting space, and doesn't recalculate information which never changes. I think that this combined with Alfred Perlsteins "second level" ("Horde") allocator code might be enough to allow the second level to reclaim page chunks at a time. I'm really loathe to suggest it, but going to a "handle" style mechanism ala Macintosh would make it very easy to move memory out from under the pointers that reference it, but it's too expensive to ven contemplate. The real problem is knowing when a region of a zone can be reclaimed. Probably, you want three reclaimation policies: 1) Never (you could default to this for debugging) 2) High watermark (when "free" exceeds the high watermark, reclaim what you can until you hit a point just above the low watermark or can't reclaim any more) 3) Dire circumstances (a callback mechanism that is a "return what you can to the system", for use in extreme low memory circumstances) There are corresponding allocation policies, as well: 1) Static (this is _my_ memory) 2) Low watermark (may or may not include initial fill to the low watermark) 3) As much as you can, up to some maximum You'd need the same zone differentiation that lives there currently too, to seperate what can and can't be allocated at interrupt time (allocation would be in N-page units, per the modified zone allocator that avoids recalculation and is space efficient). So if you wanted to allocate an mbuf (for example), they are 256 bytes, so you would get 1 page out of KVA space where a preexiting page mapping existed, yielding 16 new mbufs, and return one of those, assuming you didn't fail the allocation because you had hit an administrative limit on the total number of mbufs, or there was no memory available for backing. You could similarly chunk the KVA space into regions, based on the expected mapping size allocation units (e.g. an even number of pages for a 60 byte structure to not waste space would be 15, so the expected allocation unit would be 15 pages) to avoid fragmentation, but unless that's shown to be a problem in the real world, it's probably overkill (you'd need to change from one load type to a drastically dissimilar load type to trigger something like this, I believe). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message