[Bug 890] New: performance regression compared to 2.4.20 under tight RAM conditions

[Bug 890] New: performance regression compared to 2.4.20 under tight RAM conditions

[Martin J. Bligh]

http://bugme.osdl.org/show_bug.cgi?id=890

           Summary: performance regression compared to 2.4.20 under tight
                    RAM conditions
    Kernel Version: 2.5.73
            Status: NEW
          Severity: normal
             Owner: akpm@digeo.com
         Submitter: idan@idanso.dyndns.org


Distribution:
debian unstable

Hardware Environment:
Pentium III 700Mhz
I815E Based motherboard
64MB SDRAM 133
WD 6GB harddrive, UDMA2

Software Environment:
GCC 3.3-2
glibc 2.3.1-16
Swap partition 123MB
Swap file(on ext3 fs) of about 96MB

Problem Description:

For quite a time I had the feeling that the 2.5.x kernels perform worse than
2.4.x on my box, especially when having to do aggrassive swapping(Switching
between relatively heavyweight(ram wise) applications)

I considered this feeling subjective at first, however, eventually I took the
time to write some benchmarking code and compare results.

The code(attached) is pretty trivial, it forks, mallocs and initialize a very
large bulk of memory(I used total RAM*1.5), in order to force the system to
swap, and simulate two processes fighting on RAM space when there is no enough
of that scared resource:-)

After both processes end their work, the parent process reports on the total
running time.

The code was compiled using gcc 3.3 with -O2 parameter.

I've done 20 iterations on each of the three kernels:
Stock debian 2.4.20 (kernel-source-2.4.20-5)
Stock vanilla 2.5.73 with preempt
Stock vanilla 2.5.73 without preempt

Result are at follows:
2.4.20            : Mean - 14.1732 Max - 16.0875 Min - 12.9977 
2.5.73            : Mean - 17.1692 Max - 21.8161 Min - 15.4827
2.5.73(w/o prempt): Mean - 16.9054 Max - 19.0174 Min - 15.4137

As can be seen, the differences are quite significant, about three seconds on
average, which I believe may be related to the increased swapping time I have
encountered.

Re: [Bug 890] New: performance regression compared to 2.4.20 under tight RAM conditions

[Andrew Morton]

"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> As can be seen, the differences are quite significant, about three seconds on
> average, which I believe may be related to the increased swapping time I have
> encountered.

The 2.4 VM's virtual scan has the effect of swapping out one process at a
time.  2.5's physical(ish) scan doesn't have that side-effect.

It means that in 2.4, the lucky processes can make decent progress.  In
2.5, everyone makes equal progress and everyone thrashes everyone else to
bits.

To fix this properly we need load control: to identify when the system is
thrashing and to explicitly suspend chosen processes for a while, so other
processes can make decent progress.  A couple of people are looking at
that; I'm not sure what stage it is at.

Re: [Bug 890] New: performance regression compared to 2.4.20 undertight RAM conditions

[Idan Sofer]

> The 2.4 VM's virtual scan has the effect of swapping out one process at a
> time.  2.5's physical(ish) scan doesn't have that side-effect.
Can you elaborate on the matter of virtual vs physical VM scan? Am I
correct concluding this has to do with rmap?
> To fix this properly we need load control: to identify when the system is
> thrashing and to explicitly suspend chosen processes for a while, so other
> processes can make decent progress.  A couple of people are looking at
> that; I'm not sure what stage it is at.
If there is even an experimental patch then I will be happy to try it out,
it's probably has a lesser effect when you enough ram, but currently
that's the reason I still avoid using development kernels on that box.


-- 
Idan