Is that good or bad? It sounds like the VM cycle is doing what it's
supposed to. I've been running lots_of_forks for about 5 hours and
things have reached a steady state with free memory slowly racheting
down 1% then, apparently in a sudden fit of scanning, jumping to 2.5%.
Pretty normal looking behaviour, though I don't much like the way the
free list refill is so sporadic. I can't think of any reason why that is
good. It doesn't cost a lot of cpu though. There's been a little bit of
(useless) swapping, so I guess I can consider that path at least somewhat
tested.
Every now and then, instead of free jumping up to 2.5% it jumps up to
over 10%. I doubt that's my fault. Even though I'm missing an if
(--nr_pages) at the orphan collection point, there aren't enough orphans
to cause that effect - about 3 million out of 12 billion lru_cache_dels.
The orphans appear during or shortly after the episodes of free list
filling, as you would expect, since page_cache_release fails the trylock
whenever shrink_cache is active. There are lots of parallel
page_cache_releases going on, but they don't seem to create any
noticable number of orphans.
I think what's happening normally is this:
if (page_count(page) == 2 /* no, it's 3 */
put_page(page);
if (page_count(page) == 2 /* now it is */
if (PageLRU(page) && page_count(page) == 2)
__lru_cache_del(page);
as opposed to this:
if (page_count(page) == 2 /* no, it's 3 */
if (page_count(page) == 2 /* no, still 3 */
put_page(page);
put_page(page);
which requires hitting a 3 instruction window or on the same page.
It's not going to happen often.
Statm_pte_range looks like it's going to get even more confused about
what constitutes a shared page than it already is. The solution to
this is to examine the rmap.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/