2013/6/17 Andrew Morton <[email protected]> > That change wasn't terribly efficient - if there are any unpopulated > pages in the range (which is quite likely), fadvise() will now always > call invalidate_mapping_pages() a second time. > > Perhaps this is fixable. Say, make lru_add_drain_all() return a > success code, or even teach lru_add_drain_all() to return a code > indicating that one of the spilled pages was (or might have been) on a > particular mapping. >
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). > But I don't see why that would cause fadvise(POSIX_FADV_DONTNEED) to > sometimes take four milliseconds(!). Is it possible that a context > switch is now occurring, so the fadvise()-calling task sometimes spends > a few milliseconds asleep? >
_______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
