On Fri, 14 Jul 2000, Rik van Riel wrote:
>On Thu, 13 Jul 2000, Gerhard Mack wrote:
>
>> Yes .. I know ALL about that. But THAT isn't what I'm referring
>> to.. The thing was THRASHING. 50% of my mem for cache is
>> excessive when I'm that far into swap.
>
>"cache" includes the executable code from the programs you
>run and the shared libraries.
and swap cache. Try to run SYSRQ+M to check how many of 50% was swap
cache. Note though that swap_cache after swapins is useful, it's the swap
cache generated by the swapout that is useless and I definitely take care
of this sensible issue in classzone (and it makes an huge
difference). It's silly to even think about splitting caches and aging
when swap_cache is throwing away all the working set as soon as you
start to swap.
During swapout the swap cache is only a locking entity. Threating
differently leads to polluting the VM throwing away more interesting
informations.
I'm actually trying to make also the also-locked-pages-out-of-the-lru
things described in my past email (so that I will also avoid to wast CPU
trying to free locked entities, I only hope the tq_scheduler will be fast
enough... ;) and then I'll release a new VM patch that should be the last
step before we'll need the page->pte reverse lookup to be able to do
something of useful with the lru_mapped_cache (aka active list in your
design).
If somebody developed the code for page->pte reverse lookup I'd love if we
could synchronize since that is something completly indipendent from its
possible usages (I've not yet started writing it since I didn't yet
reached the point where I'll need it but I'm very close). Let's think
about the simple case of anon pages. SCT said "use the struct page itself
to encode the VA of the page for unshared anon pages, and keep a separate
hash of all shared anon ptes.". Problem is that virtual address per se
it's useless since the 'struct page' doesn't even tell us wich is the MM
where such VA belongs to. Also I would prefer not to walk pagetables at
all (even assuming we know also the MM, with the VA we still have to walk
pgd and pmd, we can't reach the pte in one go). OTOH being able to reach
the pte in one go may be too expensive at map/unmap time. I was thinking
at possible solution to make it to work in one go but it would cost at
least one additional memory object (incidentally cacheline sized) per
page. Consider also anonymous pages are shared after a fork and there's no
limit to the mappings of anonymous pages. Hints?
Andrea
-
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 : Sat Jul 15 2000 - 21:00:20 EST