Date: Thu, 06 Dec 2001 07:33:42 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: hackers@freebsd.org Subject: Re: Can TCP changes be put in RELENG_4? Message-ID: <3C0F8FD6.689935C1@mindspring.com> References: <local.mail.freebsd-hackers/20011205085750.I28101-100000@coredump.scriptkiddie.org> <local.mail.freebsd-hackers/200112052142.fB5LgVM53167@apollo.backplane.com> <local.mail.freebsd-hackers/3C0EF953.54CF24DB@mindspring.com> <local.mail.freebsd-hackers/3C0F0803.7010506@viasoft.com.cn> <200112061441.fB6Efw650278@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon wrote:
>
> In article <local.mail.freebsd-hackers/3C0F0D02.8AEA9E48@mindspring.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C0F8FD6.689935C1>