[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <45BF2570.5000408@symas.com>
Date: Tue, 30 Jan 2007 03:01:04 -0800
From: Howard Chu <hyc@...as.com>
To: linux-kernel <linux-kernel@...r.kernel.org>,
Rik van Riel <riel@...riel.com>
Subject: Re: Why active list and inactive list?
Rik van Riel <r...@...hat.com> wrote:
>> CLOCK-Pro is still vulnerable to the cyclic scan use case, since at that
>> time all pages will have equal distance.
>
> That's fixable. Just bias in favor of the already active
> pages and only let pages with a clearly smaller interreference
> distance replace them.
Yes, I asked Song Jiang about whether this was a normal behavior, and he
mentioned it would be an easy fix.
> Getting rid of swappiness is a very good thing, IMHO.
> I have heard about a few customer workloads that required
> changes to swappiness in order for the system to be able
> to handle their workload at all.
>
> Systems should not have to be tuned like that...
Can say that again...
>> The main problem I'm having is test cases, notably the lack thereof.
>> (and lack of time ofcourse ;-)
>
> Yes, this is always a problem. I am not aware of any complete
> test cases to test page replacement.
"Complete" would seem to be impossible. Exercise all code paths, sure. But
exercise all usage patterns, I think you're just going to have to pick a few
scenarios and hope you didn't miss anything bad.
> It would be easy to simulate some database by having part of
> the dataset be the index and referencing that in an r^2 way,
> and the rest being the data which is referenced less. At that
> point you can see how taking frequency into account helps.
> However, tests like that are simply not complete. They are
> not representative of the things most people do with their
> system.
Is *anything* really representative of "most people"? After all there is
nobody out there who is actually Joe Average.
> Something like AIM-7 suffers from the same problems...
>
> Anybody?
No great ideas spring to mind. We very seldom run in machines that are
memory-constrained, so very few of our tests are oriented toward that.
If you're just testing to see if getting rid of swappiness is feasible, I
think a fair test would just be a program that alternately touches
file-backed pages vs anonymous RAM. E.g., allocate 2GB of RAM and mmap 2GB of
a file on a machine with only 2GB of free RAM. Walk through each memory range
and make sure the balance of memory shifts as expected. Cycle that, increase
the stride on each cycle, and toss some other variations in there. You don't
need to drive real apps, you just need to have a couple of threads exerting
pressure.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists