>While Andrea's patch might look a bit inefficient, I'm
>pretty sure that the cost incurred by the tests will
>e more than made up for in increased performance...
The code runs only after a swapin. The swapin is so _long_ that the cost
of some safe test _can' t_ change performance so it' s better to leave
the paranoid in it.
>I really think that this patch should go (after some
>reviews and testing) into the 2.1 tree, as we don't
>want such a serious performance bug in the 2.2 kernel.
The patch is running _fine_ in the master server of my ISP (e-mind.com) on
2.0.36-pre9 for 17 hours. Such server has 32Mbyte of RAM and run
everything possible on it (apache, apache-ssl (two separate server and the
second one is used only occasionally to run some cgi that access
postgres), pop3, smtp, postgresql, 2/3shell, X, netscape and so on...).
The patch is stable also on my heavily loaded 2.1.122 workstation. Now
there are no more strange swapin here. But I have no SMP and no-x86
reports.
The point is that 2.1.x has the swap cache. Currently the swap cache is
only an overhead since as now it isn' t caching nothing. The swap cache
currently make sense only if nobody would write on the swapped out pages
anymore. I am currently working (also Sthepen is working on that) to give
a _sense_ to the swap cache since it seems to be the right thing to do. In
real world I am pretty sure that my funny patch would work be faster than
use the swap cache to avoid the swapin but the cache approch is more
generic (works also if the parent process remap it' s memroy for example
(pointed out by sct)).
For 2.0 instead my patch is sure the safest way to go.
Andrea[s] Arcangeli
-
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/