On Mon, Oct 20, 2003 at 10:44:09PM +0200, Official Flamer/Cabal NON-Leader wrote: > Quoth Muli Ben-Yehuda: > > > Simplest, but it's also considered a fairly ugly hack :P > > Ugly, yes. However, when you want performance and wish to avoid caching > (the latter Erez states and the first I interpolate, possibly wrongly) > and, self-admittedly, being much less conversant with optimization than > you ;-) - I suspect he would also want contiguity which, notwithstanding > the kmalloc call's availablity, is, under most real-life circumstances, > an ineffective mechanism vis-a-vis its inability to claim a significant > amount of memory, this being in use by the kernel itself and, therefore, > not available for use for any significant or interesting size, namely - > pretty much anything over a quarter meg, the latter number being the > kernel's limit in any case, as far as I remeber. > > If you have parsed the above sentence, please suggest a more elegant > solution and a less inelegant hack.
The elegance of a solution depends on how well it answers the requirements, of course, which are inadequately specified in this case. Assuming the need for a large contigous chunk of physical memory, allocating it when the kernel boots up through the usual facilities (get_free_pages) and exporting it to userspace via mmap on a device file seems and remap_page_range seem to be the prefered way to go. In general, the mem=XXX trick is "working outside the system", and thus considered ugly. Any solution that achieves the same goal while working within the confines of the system, system being the Linux kernel in this case, scores points on elegance. vis-a-vis kmalloc's slab allocator's inherent limit of 131702 bytes, if you need a single physically contigous area larger than the above, you have several options: use mem=XXX, carve it out of the memory maps we build during boot (ugly and intrusive), or use alloc_bootmem to allocate it during boot. This is probably the best way to go with stock kernels. There's also a patch floating around since 1.3.xx days called 'bigphysarea' which does pretty much what the name implies, but it has never been included AFAIK. > And yes - it is a hack, but an effective one. That was never contended, oh wielder-of-the-differential-scsi-cable. > > physical memory non cached is fairly architecture dependant, AFAIK. > > I assume x86, which may be wrong. Erez? > > ObLanguage - Ah - verbal contortions. I seem to be the Sir Humphrey of > Linux IL. Oh, said contortions are quite pleasant. Do go on ;-) Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org
signature.asc
Description: Digital signature
