Re: userspace pagecache management tool

[Rik van Riel]

Eric St-Laurent wrote:

> While I think that more user space applications should use fadvise() to
> avoid polluting the page cache with unneeded data, I still think the
> kernel should be more fair in regard to page cache management.

> Personally, I've experienced some sluggish performance after copying
> large files around. Even more when using NFS. It's difficult to file a
> bug report for "interactive feel", I don't know how to measure it. I
> just feel it's a weak aspect of the OS.

Fairness and interactiveness are very hard to quantify and
measure, which makes it hard to justify patches that improve
this behaviour.

On the other hand, patches that improve benchmark results
are easily justifyable, which makes it easy to merge those
even if it comes at the expense of fairness.

I think fairness and robustness are important, but I have
not figured out a way to justify such changes for upstream
inclusion.  Well, except perhaps by coming up with artificial
test cases, but that feels like cheating :)

> My personal opinion is that the VM seem tuned for database types
> workloads. Of course, making the page cache more fair to prevent one
> process to use most of it will most likely slowdown database type
> applications.

The database people disagree.  For one, the accessed bit
on active page gets pages gets ignored, so Linux does not
properly keep the most actively used page cache pages in
memory.

Secondly, the VM can waste quite a lot of time scanning
over the anonymous pages that it does not even want to
evict from memory.  If the VM does not plan on evicting
anonymous memory (or shared memory segments), why waste
CPU time scanning them and randomizing their LRU order?

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/