Stable pages

Posted May 12, 2011 13:00 UTC (Thu) by smurf (subscriber, #17840)
In reply to: Stable pages by djwong
Parent article: Stable pages

One kind of workload that's affected negatively would be any low-latency process which writes to disk.
When I do that, in order to guarantee that the main program responds immediately I lock the whole application in memory and use a separate writing thread.
But if you lock a couple of my process' pages when writing, that lock will affect unrelated data structures which simply happen to be on the same meory page. I can thus no longer guarantee that my main task will no longer block on random memory writes. That's not acceptable.

Stable pages

Posted May 12, 2011 13:28 UTC (Thu) by jzbiciak (guest, #5246) [Link] (1 responses)

Well, for one, you could allocate your write buffers in dedicated pages with "memalign". That might not be a bad idea anyway.

Now, on a separate note: One thing that wasn't clear to me was why this blocking only applies to file backed pages. Wouldn't anonymous pages headed toward swap also be subject to this if swap was on an integrity-checked volume?

Stable pages

Posted May 12, 2011 20:01 UTC (Thu) by djwong (subscriber, #23506) [Link]

I _think_ the swap cache tries to erase all the mappings to a particular page just prior to swapping the page out to disk, and doesn't write the page if it can't. I'm not 100% sure, however, that there isn't a race between the page being mapped back in while the swapout is in progress, so I'll check.