Posted Apr 23, 2010 18:03 UTC (Fri) by jd (guest, #26381)
Parent article: Quotes of the week
PCI allows 4K transfers in a single transaction. Thus, a 4K page can be handled in hardware atomically. Remote memory transfers (such as RDMA) also use 4K block sizes. I'm not certain, but I think most of the other standard memory hardware is also geared to 4K pages. If you can always read/insert from the very start of a block to the very end, it's convenient. No offsets to worry about, no special inserts, no mess, no fuss.
As others have noted, 4K means easier (though more resource-intensive) memory management and all of the complexities that go with juggling memory allocations.
It might actually be nice to have a multi-page-size option, where some memory uses 4K pages (specifically to exploit atomic operation benefits) and some memory uses a larger page size (for when the bottleneck is in the VM, not the bus or hardware).
Posted Apr 24, 2010 19:30 UTC (Sat) by efexis (guest, #26355)
[Link]
Unless I'm mistaken, this is only kernel mode stack space, which is why it has to be contiguous, so it'd never be used for IO. A process will generally spend most of its time running in userland, where its stack isn't affected by these issues (as its pages can be scattered in real memory). Upon requesting some IO, the kernel mode stack space might just contain a pointer to the address where the IO is to be read to, and the address of where to jump back to in userland after it's finished the IO call etc. This is of course very highly simplified (eg, it'll more likely be pointers to memory structures which will contain list of pointers to read to etc), but I believe it explains the fundamentals.