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.
*nod*
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).
http://mail.nl.linux.org/linux-mm/
http://www.linux.eu.org/Linux-MM/
> 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
idea.
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:20 EST