Re: [patch] balanced highmem subsystem under pre7-9

From: Rik van Riel (
Date: Fri May 12 2000 - 08:20:19 EST

On Fri, 12 May 2000, Andrea Arcangeli wrote:
> On Fri, 12 May 2000, Ingo Molnar wrote:
> >what bad effects? the LRU list of the pagecache is a completely
> >independent mechanizm. Highmem pages are LRU-freed just as effectively as
> >normal pages. The pagecache LRU list is not per-zone but (IMHO correctly)
> >global, so the particular zone of highmem pages is completely transparent
> It shouldn't be global but per-NUMA-node as I have in the classzone patch.


This change is in my source tree too (but the active/inactive
page list thing doesn't work yet).

> >and irrelevant to the LRU mechanizm. I cannot see any bad effects wrt. LRU
> >recycling and the highmem zone here. (let me know if you ment some
> >different recycling mechanizm)
> See line 320 of filemap.c in 2.3.99-pre7-pre9. (ignore the fact
> it will recycle 1 page, it's just because they didn't expected
> pages_high to be zero)

Indeed, pages_high for the higmem zone probably shouldn't be zero.

pages_min and pages_low: 0
pages_high: 128??? (free up to 512kB of high memory)

> >'balanced' means: 'keep X amount of highmem free'. What is your point in
> >keeping free highmem around?
> Assuming there is no point, you still want to free also from the
> highmem zone while doing LRU aging of the cache.

True, but this just involves setting the watermarks right. The
current code supports the balancing just fine.

> And if you don't keep X amount of highmem free you'll break if
> an irq will do a GFP_HIGHMEM allocation.

GFP_HIGHMEM will automatically fallback to the NORMAL zone.
There's no problem here.

> Note also that with highmem I don't mean not the memory between
> 1giga and 64giga, but the memory between 0 and 64giga.

Why do you keep insisting on meaning other things with words than
what everybody else means with them? ;)

> Please read my emails on linux-mm of a few weeks ago about
> classzone approch.

I've read them and it's overly complex and doesn't make much
sense for what we need.

> I can forward them to linux-kernel if there is interest (I don't
> know if there's a web archive but I guess there is).

> If the current strict zone approch wouldn't be broken we could
> as well choose to split the ZONE_HIGHMEM in 10/20 zones to
> scales 10/20 times better during allocations, no?

This would work just fine, except for the fact that we have
only one pagecache_lock ... maybe we want to have multiple
pagecache_locks based on a hash of the inode number? ;)

> Is this argulemnt enough to make you to at least ring a bell
> that the current design is flawed?

But we *can* split the HIGHMEM zone into a bunch of smaller
ones without affecting performance. Just set zone->pages_min
and zone->pages_low to 0 and zone->pages_high to some smallish
value. Then we can teach the allocator to skip the zone if:
1) no obscenely large amount of free pages
2) zone is locked by somebody else (TryLock(zone->lock))

This will work just fine with the current code (plus these
two minor tweaks). No big changes are needed to support this



The Internet is not a network of computers. It is a network
of people. That is its real strength.

Wanna talk about the kernel? / #kernelnewbies

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:20 EST