Ok its a bit better than a single PII 400 MHz :-)
... with less than 64MB the break downs are going to be the common state
whereas with 128MB the system is usable. Nevertheless whenever both make
loops taking the filesystem tree at the same time, the system performance
slows down dramatically (a `break down').
> > What's about a `PG_recently_swapped_in' bit for pages which arn't found
> > anymore with the swap cache? This isn't a prediction but a protection
> > against throwing out the same page in the following cycle.
>
> I am not sure to have understood well but if the page is been throw out
> from the swap cache it means that the page is gone and so it will be
> difficult to mark the page PG_recently_swapped_in ;). But we could use the
> same logic with a bit in the swap entry to handle that (we have 6 custom
> bit to use and only one is used right now, and it's SHM_SWP_TYPE).
This hypothetical bit should only be set if the page is read physical
from the swap device/file. That means it would take one step more
to swap out this page again (test_and_clear_bit of both
PG_recently_swapped_in and PG_referenced).
>
> But I don't think it's the right approch. The swap_cache should just be
> able to throw out only the right pages. See below ...
>
> > > People keep playing with ignoring PG_referenced in shrink_mmap for the
> > > swap cache,
> > > because it doesn't seem terribly important. If you could demonstrate
> > > this is a problem we can stop ignoring it.
>
> Eric, it's important infact. I am handling aging in the swap cache here.
> That's an _important_ point for performances. I don't remeber if I pointed
> out this before.
Werner
-
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/