Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!nntp.coast.net!news-res.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!in3.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Who (or what) is Jesus Monroy?
Date: Wed, 31 Jul 1996 17:33:04 -0700
Organization: Me
Lines: 61
Message-ID: <31FFFB40.5CAAD785@lambert.org>
References: <DttF16.1Bn@ritz.mordor.com> <DtuFHy.6CG@nemesis.lonestar.org> <4rddc3$5ip@news.wco.com> <31DB58FE.582527CC@lambert.org> <4rhb16$5nd@news.wco.com> <31DD7B83.5704792A@lambert.org> <4ta1vc$njn@news.wco.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Jesse Monroy wrote:
] : If you want, you can do your SLAB allocation in a page from a
] : given zone; it's pretty much irrelevant, since the issue of
] : memory bus arbitration (which seems to be your problem with
] : DMA) is taken care of with the per processor pools that are
] : refilled-from/drained-to the global pool at sparse intervals
] : (Vahalia, "UNIX Internals: The New Frontiers", Chapter 12,
] : _Kernel Memory Allocation_, 12.9 _A Hierarchical Allocator
] : for Multiprocessors_ **).
] :
] A global pool is not a good idea. does not scale.
A global pool is what you have if you have one memory bus
(ie: you want to run on commodity hardware instead of paying
another 50% premium for someone's proprietary box.
You mitigate the problems with the global pool by heirchical
locking and per processor zone allocation. It is very unlikely
that a processor will be aloocating/deallocating pages from the
global pool at the same time another processor needs to do the
same thing. If they do, then you have set your watermarks
incorrectly and can fix the problem via tunables.
] : SLAB allocation also tends to fail to perform when its biggest
] : excuse is taken away (for instance, when the VM and buffer cache
] : have been unified).
] :
] Don't know SLAB yet, sounds like a flat memory model.
] I assume SLAB follows traditional RAS x CAS ideology.
] NOT GOOD. Even bank switching will bogg...
No. SLAB allocation is what Solaris and SVR4/SMP currently do.
It is page-based allocation, where the page is broken up into
allocation units via btree. The win it gives is homogenous
page contents, so pages tend to contain objects of roughly the
same locality and scoping. This saves you from fragging kernel
memory across several processors using similar memory objects
(ie: streams buffers or whatever). You really need to read
the Vahalia book, chapter 12, in it's entirety... he is fond
of the SLAB allocation, but I think it missed the mark. I don't
think Vahalia was thinking of anything over the order of 8
processors in an SMP system (the APIC addressing for virtual
wire mode in the Intel Multiprocessing specification is 5 bits,
yielding 32 processors, max).
] The next question might be will shadowing advantage
] the tradditional linear or matrix memory layout.
] from an engineering stand point IT's done.
] Look at embedded system cira 1960 to 1985.
SRAM doesn't scale as well as DRAM; it wants too much realestate
to be economical. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.