davidv1992 wrote:
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
As you like.
Quote:
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.
Depends on. My storage cache driver uses free memory, and if the allocator requests a new frame, the disk cache is consulted. In my model if storage cache would not be free to other processes, you won't be able to allocate memory as soon as storage subsystem initialized, since it eats up all.
Quote:
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.
No it's not, if you do the housekeeping, defragmentation will happen too.
Quote:
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.
Wait a minute. Slowing down under some rare circumstances and "crash"/"fail" quite different!!! Not to mention that you could do the defragmentation when the cpu is idle, so the user won't notice. If you're right, you shouldn't implement swapping, as it will seriously hurt performance too.
Quote:
More space for the FIFO won't solve the problem unless one reserves a lot of memory for it.
You drop words "more space" and "lot of memory" too easily, without comparing the real memory requirement with stack's. I say 4M is a lot of memory. 128k isn't, and it allows you to handle more than 10,000 fragments. The exact number of fragments depends on how your OS work, you have to calibrate it. For me 512 is enough. Period.
Quote:
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.
Basically you're right, you just wrong about the volumes, and your reasonable understanding lacks some key part that makes the thing work.
XenOS wrote:
pushing pages of the stack isn't that time consuming I doubt it matters much
It does. Think it over again. With stack you have to do 2^32 pushes, whilst fifo needs 2 or 3 (one for each free entry in E820). Significant difference. Again, you're wrong about the volume, you assume that both methods require same number of pushes, but it's simply not true, they have different amount of input.