Date: Sun, 24 Feb 2002 01:15:52 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <alfred@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, current@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG> Subject: Re: malloc_bucket() idea (was Re: How to fix malloc.) Message-ID: <3C78AF48.5493B893@mindspring.com> References: <200201051752.g05Hq3gG074525@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <XFMail.020114020307.jhb@FreeBSD.org> <200201241022.g0OAMISM093913@faber.r.dl.itc.u-tokyo.ac.jp> <20020124024534.V13686@elvis.mu.org> <200202131739.g1DHdZT5023794@rina.r.dl.itc.u-tokyo.ac.jp> <200202190945.g1J9j9kg076110@rina.r.dl.itc.u-tokyo.ac.jp> <200202232051.g1NKpE741310@apollo.backplane.com> <20020223211449.GJ80761@elvis.mu.org> <200202232243.g1NMhZP49110@apollo.backplane.com> <20020224003739.GL80761@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Matthew Dillon <dillon@apollo.backplane.com> [020223 14:43] wrote: > > This is approximately what I am thinking. Note that this gives us the > > flexibility to create a larger infrastructure around the bucket cache, > > such as implement per-cpu caches and so on and so forth. What I have > > here is the minimal implementation. > > I strongly object to this implementation right now, please do not > commit it. I already explained to you how to make the problem > go away but instead you insist on some complex api that pins > memory down like the damn zone allocator. It's not needed, so > please don't do it. Actually, the zone allocator is not far off, I think. Imagine if the entire possible KVA space (real RAM + swap) was preallocated PTEs. Allocations could treat it as anonymous memory, for which a mapping process was not required, and all allocations would be interrupt safe by default, without having to special case the code one way or the other. This seems, to me, to be the right idea. The only issue left is that the maps take real memory that is wired down. This raises the possibility of adding to the swap where swap + RAM << KVA && swap + RAM + new_swap <= KVA, which would imply mappings bneing required on the adding of swap (via swapon). Not that painful, but it does imply a 1:1000 limit ratio on real vs. virtual RAM to get to the page mapping overhead. 4M pages would cover some of that problem... but making allocations swappable is often desirable, even in the kernel, so you would need to special case those mappings... and 4M and 4K pages play badly together, unless you know what you are doing, and you know the undocumented bugs (c.v. the recent AMD AGP thing). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C78AF48.5493B893>