> On Fri, 2 Nov 2001, Stephan von Krawczynski wrote:
> > To clarify this one a bit:
> > shrink_cache is thought to do what it says, it is given a number
> > pages it should somehow manage to free by shrinking the cache.
> > patch does is go after the _whole_ list to fulfill that.
> I would suggest a slight modification: make "max_mapped" grow as the
> priority goes up.
> Right now max_mapped is fixed at "nr_pages*10".
> You could have something like
> max_mapped = nr_pages * 60 / priority;
> instead, which might also alleviate the problem with not even
> scan much of the inactive list simply because 99% of all pages are
> That way you don't waste time on looking at the rest of the inactive
> until you _need_ to.
Wait a minute: there is something illogical in this approach:
Basically you say by making max_mapped bigger that the "early exit"
from shrink_cache shouldn't be that early. But if you _know_ that
merely all pages are mapped, then why don't you just go to swap_out
right away without even walking through the list, because in the end,
you will go to swap_out anyway (simply because of the high percentage
of mapped pages). That makes scanning somehow superfluous. Making it
priority-dependant sounds like you want to swap_out earlier the
_lower_ memory pressure is. In the end it sounds just like a hack to
hold up the early exit against every logic (but not against some
benchmark of course).
It doesn't sound like the right thing.
Is the inactive list somehow sorted currently? If not, could it be
implicitly sorted to match this criteria (not mapped versa mapped), so
that shrink_cache finds the not-mapped first (with a chance to fulfill
nr_pages-request). If it isn't fulfilled and hits the first mapped
page, it can go to swap_out right away, because more scanning doesn't
make sense and can only end in swap_out anyways.
I am no fan of complete list scanning, but if you are looking for
something you have to scan until you find it.
PS: I am still no pro in this area, so I try to go after the global
picture and find the right direction...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:17 EST