Re: 23 second kernel compile (aka which patches help scalibility on

[Rik van Riel]

On Mon, 11 Mar 2002, Andrea Arcangeli wrote:
> On Fri, Mar 08, 2002 at 09:47:04PM -0800, Martin J. Bligh wrote:
> > Big locks left:
> >
> > pagemap_lru_lock
> > 20.2% 57.1%  5.4us(  86us)  111us(  16ms)(14.7%)   1014988 42.9% 57.1%    0%
>
> I think this is only due the lru_cache_add executed by the anonymous
> pagefaults. Pagecache should stay in the lru constantly if you're
> running in hot pagecache as I guess. For a workload like this one
> keeping anon pages out of the lru would be an obvious win.

... but only if you're really dealing with anonymous pages,
I suspect that people will use NUMA machines more for workloads
where most pages belong to mappings, because if a scientific
calculation can be split out to a cluster you don't need the
cost of NUMA hardware.

Not sure if my guess is right though ;)

> It's a tradeoff. Just like the additional memory/cpu and locking
> overhead that rmap requires will slowdown page faults even more than
> what you see now, with the only object to get a nicer pagout behaviour
> (modulo the ram-binding "migration" stuff where rmap is mandatory to do
> it instantly and not over time).

Rmap will also make it possible to have the lru lock per
zone (or per node), which should give rather nice behaviour
for large SMP and NUMA systems ... even if the workload
isn't made up of anonymous pages ;)

Btw, what is the "ram binding migration stuff" you are
talking about and why would rmap not be able to do it in
a nice way ?

regards,

Rik
-- 
<insert bitkeeper endorsement here>

http://www.surriel.com/		http://distro.conectiva.com/