On Thu, Jan 19, 2012 at 09:52:11PM +0100, Jan Kara wrote: > anything. So what will be cheaper depends on how often are redirtied pages > under IO. This is rather rare because pages aren't flushed all that often. > So the effect of stable pages in not observable on throughput. But you can > certainly see it on max latency... I see your point. A problem with migrate though is that the page must be pinned by the I/O layer to prevent migration to free the page under I/O, or how else it could be safe to read from a freed page? And if the page is pinned migration won't work at all. See page_freeze_refs in migrate_page_move_mapping. So the pinning issue would need to be handled somehow. It's needed for example when there's an O_DIRECT read, and the I/O is going to the page, if the page is migrated in that case, we'd lose a part of the I/O. Differentiating how many page pins are ok to be ignored by migration won't be trivial but probably possible to do. Another way maybe would be to detect when there's too much re-dirtying of pages in flight in a short amount of time, and to start the bounce buffering and stop waiting, until the re-dirtying stops, and then you stop the bounce buffering. But unlike migration, it can't prevent an initial burst of high fault latency... -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
