Date: Sun, 29 Jul 2001 13:52:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Zhihui Zhang <zzhang@cs.binghamton.edu>, Alfred Perlstein <bright@mu.org>, vishwanath pargaonkar <vishubp@yahoo.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: cluster size Message-ID: <3B6477A0.5270E5F8@mindspring.com> References: <Pine.SOL.4.21.0107272018280.13783-100000@opal> <3B632429.D3FA2EB0@mindspring.com> <20010728194727.A54256@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: > > So, in general: > > > > 1) Only some allocators can be used at interrupt time > > 2) If they can, they must precommit kernel address space > > to the task > > 3) Once memory is allocated from one of these pools, it > > is never returned to the system for reuse > > This (3) only applies to the zone allocator. With maps, > you *can* free back to the map and unwire the wired pages > (freeing physical memory). FWIW, I am allocating my mbuf's in machdep.c, very in on the kernel life cycle, out of real physical memory. I have a real problem with the way it currently works in 4.3 (which is what I am using; I dislike -current, mostly because it is going in the wrong direction), and with the way the 5.x code works. In both cases, the code will permit a map allocation without the underlying pages being allocated (indeed, you point to this as a "feature" of the -current code). The problem with this is when you go to get a backing page, and there is nothing there. The allocation fails, but it returns the map entry location, and when an attempt is subsequently made to access the memory in extreme low memeory conditions, the wiring of a free backing page fails, with the inevitable consequences. The allocation should be falied because of the unavailability of a backing page. As my system currently exists, I don't have these problems -- but I do have the issue of the memory being allocated. Realize that when the page map is not sparse -- say on a system with 4G of physical RAM -- there are a lot of basic assumptions in both the 4.3 and -current schemes which simply are not true. This includes the overallocation of page tables for the kernel on the assumption that the relative size of physical RAM is small, compared to the kernel virtual address space. > > 4) The general malloc() code _can not_ be used at interrupt > > time in FreeBSD (but SVR4's allocator can). > > Huh? Do you realize that in much much earlier versions > of FreeBSD (not long after the import from 4.4BSD, or whatever > it was uipc_mbuf.c was initially imported from) all _MBUFS_ were > allocated directly with malloc()? Obviously, mbufs are allocatable > at interrupt time (and always were, afaic remember). All that you > have to make sure to do, when allocating at interrupt time is to > allocate with the M_NOWAIT flag. Yes, I realize this. I also realize why it was changed: because you are unlikely to be able to malloc at interrupt, unless you have a sufficient fre reserve to be able to do so. This approach was inferior, in that it tended to result in quick failure in receiver livelock cases, which was then aggravated by the lack of acknoldegements by the server. The current approach is a tiny bit better, in that it permits allocation at interrupt, which means that you buffer up the data, but you still have all of the issues which Jeff Mogul pointed out in his landmark paper. As far as SMP allocators go, you need to get rid of all locks in the common code path, period. This isn't really something you can negotiate on. The additional locks in your and Alfred's allocators are the direct result of not having a second level coelescing cache, per the Dynix allocator (see Uresh VAhalia's book, in particular, chapter 12. As far as interrupt allcoation goes, there are two things: 1) The available kernel virtual address space needs to be mapped so it can be allocated 2) The allocations need to be failed, even if mapping space is available, if backing space is not Addressing these issues would permit all kernel memory allocations to occur at interrupt. I'm not sure if Steve Baumel (the person largely responsible for the SVR4 VM system) ever wrote a paper on his approach, or not, but with the Solaris source code available, his code is now available for study. -- 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?3B6477A0.5270E5F8>