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/