turdus wrote:
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.
Once again, in the situation of high load (which is where it would most matter) these pages probably won't be in the TLB anyway (and they definnitely will not be in the processors cache), so it will not matter
Quote:
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.
When that memory is used for storage cache it isn't free, and thus shouldn't be in the structure that manages free memory anyway.
Quote:
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.
As already stated by several others, the important case is that of a system under high load and/or running for long amounts of time. Even the laptop I'm writing this on regularly spends hours being on and running several tasks, most of which are system tasks. Fragmentation will happen, and the potential ammount of fragmentation is WAY bigger than what you are allowing for, even on systems with relatively little memory.
Quote:
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.
The moment you need to run a defragmenter you will be taking quite a bit of the memory bandwith of the system, which will seriously hurt performance. Of course you could implement some sort of queuing of free pages that cannot be returned to the main pool and have background tasks handle them, but that queue itself might grow quite big, and would certainly add a lot of complexity to the memory system (ie. greater chance for bugs). More space for the FIFO won't solve the problem unless one reserves a lot of memory for it.
Quote:
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.
If any of the points I made point to ignorance on my part I apologize, but I do believe that I have a reasonable understanding of your system, enough to state those things I see as flaws.
turdus wrote:
XenOS wrote:
I guess the point why the stack-based allocator consumes almost no memory is the following: The stack contains only the free pages. So if many pages are free (say, nearly 4 GB), you need a large stack to hold all of them (in this case 4 MB). However, spending lots of memory is not an issue when almost all of your physical memory is free.
Once you allocate memory, you pop more and more entries off the top of the stack. Thus, the memory which holds the top of the stack is not needed anymore and can be deallocated. The only information the stack needs to keep is the location of free pages, and when the number of free pages drops below 1024, the whole stack fits into a single 4 kB page and consumes almost no physical memory.
When you free pages again and the stack needs to grow, simply map freed pages to the top of the stack when necessary.
Correct, but you compare the best case (free pages drops below 1024) with the worst case (fragments exceed 512). And you can handle fifo's buffer dynamically as well. The point is that you have to allocate/deallocate memory for stack (4k-4M), while fifo can work on 1 or 2 preallocated pages as well. Let's see a worst case where same amount of memory required:
stack: all memory free, 4M
fifo: contains more than half million fragements, 4M
And the difference is even bigger if it comes to 64 bit. The stack would consume 256G for full RAM (2^48, 256Tb), while fifo can handle all of it in 4M easily. Scalability matters! Do not forget that the free frame stack (as well as fifo) has to be filled in at boot time when almost every frame is free!
This is one point you do have. At boot time stack cost some ammount of time to fill, and your system is no doubt faster. However as this is a one time penalty at boot and the process of pushing pages of the stack isn't that time consuming I doubt it matters much, unless you get at really big ammounts of memory, in which case it could be mitigated by doing the initial allocations of each frame from a different structure than the stack without much effort.