<div class="gmail_quote">2013/6/17 Andrew Morton <span dir="ltr"><<a href="mailto:akpm@linux-foundation.org" target="_blank">akpm@linux-foundation.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That change wasn't terribly efficient - if there are any unpopulated<br>
pages in the range (which is quite likely), fadvise() will now always<br>
call invalidate_mapping_pages() a second time.<br>
<br>
Perhaps this is fixable.  Say, make lru_add_drain_all() return a<br>
success code, or even teach lru_add_drain_all() to return a code<br>
indicating that one of the spilled pages was (or might have been) on a<br>
particular mapping.<br></blockquote><div><br>Following our tests results, that was the call to lru_add_drain_all() that causes the problem. The second call to invalidate_mapping_pages() isn't really important. We tried to compile a kernel with the commit introducing this change but with the "lru_add_drain_all()" line removed, and the problem disappeared, even if we called two times invalidate_mapping_pages() (as the rest of the commit was still here).<br>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I don't see why that would cause fadvise(POSIX_FADV_DONTNEED) to<br>
sometimes take four milliseconds(!).  Is it possible that a context<br>
switch is now occurring, so the fadvise()-calling task sometimes spends<br>
a few milliseconds asleep?<br></blockquote><div><br><br></div></div>