linux-kernel - Re: Why active list and inactive list?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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/