The trouble with stable pages [LWN.net]

The trouble with stable pages

Posted Mar 15, 2012 13:10 UTC (Thu) by Spudd86 (guest, #51683)
In reply to: The trouble with stable pages by slashdot
Parent article: The trouble with stable pages

Read the article, it's because the writeback might be triggered by memory pressure and COW will make the memory pressure worse, personally I like the third option, which was delay the checksum until the page is actually about to be under IO, which will make the time that an app could block in much shorter (basically exactly how long it takes to do the checksum and write the one page, which is basically a short fixed constant amount of time for a given system)

to post comments

The trouble with stable pages

Posted Mar 15, 2012 13:54 UTC (Thu) by slashdot (guest, #22014) [Link] (1 responses)

I am suggesting to only do the copy if the application tries to access the page under writeback and takes the fault, which is hopefully relative rare (especially if the checksum is also delayed as you suggest).

With a single program, the worst that can happen is that the COW operation itself blocks because no pages are available, which is no worse than blocking on disk access.

Also, the additional pages are bound by the number of pages under writeback, which should be bounded by a value proportional to the number of simultaneous requests the hardware supports, which is small, so it shouldn't be an issue even with multiple programs.

And of course, systems with huge RAID arrays supporting bazillions of simultaneous request are also likely to have huge amounts of RAM.

The trouble with stable pages

Posted Mar 15, 2012 14:01 UTC (Thu) by slashdot (guest, #22014) [Link]

Oh, and yes, waiting 1-2 seconds before writing out dirty pages is a good idea for data coming from mmap and from write() calls only partially writing that page (but not for those entirely contained in the write() range), as it also reduces the likelyhood of conflicts.