Messages in this thread | | | Date | Sat, 17 Jul 1999 01:13:22 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New kernel/resource.c |
| |
On Sat, 17 Jul 1999, Rogier Wolff wrote: > > Reasons that I can come up with right now: > - It has an educational effect. (It tells people where their 3G kernel > virtual addressing space went, it explains why you should use mem=960M > instead of mem=1024M if you have 1G of RAM.) > - ioremap & vmalloc are parcelling out a resource, that nicely fits the > model.
I certainly agree that the model fits very well.
Whether it really is needed is another matter. VM isn't _that_ scarce, although it might be a nice visualization tool for module loading etc.
> Not convinced? Oh well, at least you straightened me out.... ;-)
I'd be more convinced if you could show (for example) that you can actually simplify "vmalloc()" by using this to find empty holes. Or something like that.
Right now vmalloc() already does its own resource handling. That may be a mistake in itself: we might be able to get rid of the vmalloc() resource handling and rely entirely on the concept of a "virtual memory resource" for this. If so, that would indeed be a major benefit, and would convince me in a jiffy.
But there may well be reasons why vmalloc() is better off doing the resource management itself. I'm off to bed, I'll leave that to somebody else to look into..
If this were to be done, it would be something like this:
vm_resource --+-- user space: 0-3GB 0-4GB | +-- kernel 1:1 mapping 3GB-3.2GB | | | +-- ISA legacy region | +-- vmalloc arena 3.3GB-3.9GB | | | +-- module1 | | | +-- module2 | +-- fixmap arena 3.9GB - 4GB | +-- io_apic | +-- local_apic
where the "vmalloc" arena would be a sub-resource and have the actual vmalloc'ed areas inside it (that shows the idea behind sub-resources: this way we can use the general resource management functions to find empty areas without having to worry about empty areas in some other location).
I can certainly see the visualization as being fun and useful,
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |