davidv1992 wrote:
The fact that it is in the kernel will guarantee that almost everything that isn't used on every interrupt will probably not reside in the cache on first access anyway, so the cache argument is moot
Allocating large amount of frames would. As you pop new values from stack, you're increasing the stack pointer constantly, it's most likely that you will cross a page border sooner or later.
Quote:
The amount of memory you save because the amount of data on the stack is smaller is moot because that memory isn't used for anything else anyway.
I do not understand your point. "It isn't used for anything else"? Speak for yourself, I would rather use it for storage cache. And 1 page *is* smaller than 2^32*4 bytes.
Quote:
Furthermore you make the argument that a maximum of 512 fragments on physical memory is enough.
Stated empirically. It's rare that I see more than 3 fragments. I'm testing it for a while.
Quote:
...in which case your system fails horribly.
Where did you get that from?!? First: you can use more space for fifo, second: if this occurs, it calls defragmenter and/or swapper. If you can't write a swapper of your own, your implementation will fail horribly, I agree on that.
Quote:
This all combined with the fact that it is a far more complex system than the other two I would strongly recommend against using it.
Don't like it, don't understand it, so don't use it.