Stable pages, posible corner cases
Stable pages, posible corner cases
Posted May 12, 2011 18:07 UTC (Thu) by davecb (subscriber, #1574)In reply to: Stable pages by djwong
Parent article: Stable pages
In a previous life I was involved in the performance measurement of coalescing disk writes, and we found a very large number of sequential writes could be coalesced into single writes, and then adjacent blocks coalesced into larger singe writes. This paid off particularly well when a disk was being handed writes at or beyond it's capacity, by removing unneeded writes. I think I still have the graphs somewhere (;-))
I'll comment on the non-sequential case in a sec, after I look at my archive.
--dave
Posted May 12, 2011 18:49 UTC (Thu)
by jzbiciak (guest, #5246)
[Link] (1 responses)
http://lxr.free-electrons.com/source/mm/page-writeback.c
That's what makes it so hard (at least for me) to reason about what workloads would get hurt, since there's not a simple, immediate relationship between "application dirtied a page" and "page got scheduled for writeback." You need both of those things to happen *and* the application must subsequently try to dirty the page further before you hit the page-block.
I guess you could get some negative interactions more immediately if a 'write' call scheduled a writeback for part of a page, and then the app immediately resumed filling the rest of the page. Still, I don't think a write() syscall triggers an immediate writeback on most calls. Take a look at 'queue_io' around line 277:
http://lxr.free-electrons.com/source/fs/fs-writeback.c
Only the oldest dirtied pages get flushed, as I read that.
Posted May 12, 2011 19:23 UTC (Thu)
by davecb (subscriber, #1574)
[Link]
Stable pages, posible corner cases
Stable pages, posible corner cases