[lttng-dev] [-stable 3.8.1 performance regression] madvise POSIX_FADV_DONTNEED

[Raphaël Beamonte]

2013/6/17 Andrew Morton <akpm at linux-foundation.org>

> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20130617/09a4d679/attachment.html>