VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35, and 2.5.35 + mm1

VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35, and 2.5.35 + mm1

[Bill Hartner]

I ran VolanoMark 2.1.2 under memory pressure to test rmap.
                             ---------------
Kernels tested were :

     * 2.5.26
     * 2.5.26 + Dave McCracken 2.5.26-rmap patch
     * 2.5.35
     * 2.5.35 + Andrew Morton 2.5.35-mm1 patch

The SUT was an 8-way 700 Mhz PIII system with 3 GB mem.
A single 2 GB swap partition.
IBM JR2RE 1.3.1 cxia32131-20020302.

When VolanoMark was ran with 4 GB mem, there is about 500 MB free mem.
The JVM heaps totaled 3 GB.
When the test was ran with 3 GB mem 1 GB of swap space was required.

VolanoMark was ran in loopback mode - client and server on same system.
The JVM for the VolanoMark client used a 1536 MB heap.
The JVM for the VolanoMark server used a 1536 MB heap.
The number of messages was set at 25000 and number of rooms at 10.
The JVM does not fork - it uses pthreads.
10 rooms creates 400 client pthreads and 400 server pthreads.

More info on VolanoMark at http://www.volano.com/benchmarks.html

When the JVM heaps are exhausted (memory allocation failure) garbage
collection (GC) is done by the JVM.  GC usually reclaims about 99 % of the
heap.  The client JVM uses its heap more heavily than the server.  The
client JVM will GC about 26 times during the test and the server JVM will GC
about twice.  The meta data for the heap is _not_ in the heap itself, so
when GC is run the JVM does _not_ touch every page in the heap.

As the 3 GB mem test runs (for 2.5.26 baseline) :

   HighFree goes to ~2MB at about  240 seconds into the test
   Low Free goes to ~6MB at about  600 seconds into the test
   SwapFree goes to ~1GB at about 1245 seconds into the test
   The test ends         at about 1966 seconds (33 minutes)

VolanoMark was ran 1 time for each kernel.

The results for the 3 GB mem test were :
                    --------
%sys/%user = ratio of system CPU utilization to %user CPU utilization.

kernel      msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
----------- -----  ---- ----------  ------------  ------------  ------------
2.5.26      51824  96.3 1.42        1,987,024 KB  2,148,100 KB  4,135,124 KB
2.5.26rmap  46053  90.8 1.55        3,139,324 KB  3,887,368 KB  7,026,692 KB
2.5.35      44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
2.5.35mm1   39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB

* used pgin/pgout instead of swapin/swapout since /proc/stat changed.

2.5.35 had the following errors after high and low mem were exhausted
for the 3 GB test :

kswapd: page allocation failure. order:0, mode:0x50
java: page allocation failure. order:0, mode:0x50

On 2.5.35, I replaced the printk of the page allocation error with a global
counter and ran 2.5.35 again.  The global counter indicated 5532 page
allocation errors during the test and the throughput was 44371 msg/s.

These errors do not occur on 2.5.35 + mm1

The results for the 4 GB mem test were :
                    --------
kernel      msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
----------- -----  ---- ----------  ------------  ------------  ------------
2.5.26      55446  99.4 1.40        0             0             0
2.5.35      52845  99.9 1.38        0             0             0
2.5.35mm1   52755  99.9 1.42        0             0             0

2.5.26 vs 2.5.26 + rmap patch
-----------------------------
It appears as though the page stealing decisions made when using the
2.5.26 rmap patch may not be as good as the baseline for this workload.
There was more swap activity and idle time.

46053/51824 = 88.9 %, VolanoMark runs 11 % slower with the 2.5.26 rmap patch
when compared to 2.5.26 for the 3 GB test.

Here is a chart that compares (a) swap rate (swapin + swapout)
and (b) CPU utilization for on 2.5.26 and 2.5.26+rmap patch.

www-124.ibm.com/developerworks/opensource/linuxperf/volanomark/091602/v26.gif

2.5.35 vs 2.5.35 + mm1 patch
-----------------------------

The 2.5.35 + mm1 patch does not have the page allocation errors.  
The swapin and swapout are not reported in /proc/stat for this patch.
So I used /proc/stat pgin and pgout to determine swap io rate.

39679/51824 = 77.4 %, VolanoMark runs 22 % slower with the 2.5.35 mm1 patch
when compared to 2.5.26 for the 3GB test.

Bill Hartner
IBM Linux Technology Center
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35, and 2.5.35 + mm1

[Andrew Morton]

Bill Hartner wrote:
> 
> I ran VolanoMark 2.1.2 under memory pressure to test rmap.
>                              ---------------

Interesting test.  We really haven't begun to think about these
sorts of loads yet, alas.  Still futzing with lists, locks, 
IO scheduling, zone balancing, node balancing, etc.

Could someone please provide me with a simple set of instructions
to get volanomark up and running?   Including where to find a
JVM, etc?  I haven't even been able to locate the download for
volanomark.  Maybe that's a hint...

> ...
> 
> kernel      msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
> ----------- -----  ---- ----------  ------------  ------------  ------------
> 2.5.26      51824  96.3 1.42        1,987,024 KB  2,148,100 KB  4,135,124 KB
> 2.5.26rmap  46053  90.8 1.55        3,139,324 KB  3,887,368 KB  7,026,692 KB
> 2.5.35      44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> 2.5.35mm1   39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB

Strange that increased CPU utilisation (in userspace!) doesn't correlate with
increased throughput.
 
> * used pgin/pgout instead of swapin/swapout since /proc/stat changed.
> 
> 2.5.35 had the following errors after high and low mem were exhausted
> for the 3 GB test :
> 
> kswapd: page allocation failure. order:0, mode:0x50
> java: page allocation failure. order:0, mode:0x50

That's OK.  These warnings should have been suppressed, but a
bug in the suppression code lets them escape.
 
> On 2.5.35, I replaced the printk of the page allocation error with a global
> counter and ran 2.5.35 again.  The global counter indicated 5532 page
> allocation errors during the test and the throughput was 44371 msg/s.
> 
> These errors do not occur on 2.5.35 + mm1
> 
> The results for the 4 GB mem test were :
>                     --------
> kernel      msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
> ----------- -----  ---- ----------  ------------  ------------  ------------
> 2.5.26      55446  99.4 1.40        0             0             0
> 2.5.35      52845  99.9 1.38        0             0             0
> 2.5.35mm1   52755  99.9 1.42        0             0             0
> 
> 2.5.26 vs 2.5.26 + rmap patch
> -----------------------------
> It appears as though the page stealing decisions made when using the
> 2.5.26 rmap patch may not be as good as the baseline for this workload.
> There was more swap activity and idle time.

Do you have similar results for 2.4 and 2.4-rmap?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35, and 2.5.35 + mm1

[Rik van Riel]

On Tue, 17 Sep 2002, Andrew Morton wrote:
> Bill Hartner wrote:
> >
> > I ran VolanoMark 2.1.2 under memory pressure to test rmap.
> >                              ---------------
>
> Interesting test.  We really haven't begun to think about these
> sorts of loads yet, alas.  Still futzing with lists, locks,
> IO scheduling, zone balancing, node balancing, etc.

Ummm ?  Performance under memory pressure was the whole reason I
started the rmap vm in the first place ;)

It's kind of strange to see all the balancing work being thrown
out the window now because it's "not interesting"...

> > 2.5.26 vs 2.5.26 + rmap patch
> > -----------------------------
> > It appears as though the page stealing decisions made when using the
> > 2.5.26 rmap patch may not be as good as the baseline for this workload.
> > There was more swap activity and idle time.
>
> Do you have similar results for 2.4 and 2.4-rmap?

If Bill is going to test this, I'd appreciate it if he could use
rmap14a (or newer, if I've released it by the time he gets around
to testing).

Btw, I'm about to backport the pte_chains from slabcache patch and
somebody from #kernelnewbies is looking at dmc's direct pte pointer
patch. I might integrate more 2.5 stuff in 2.4-rmap if people want
it.

regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35,and 2.5.35 + mm1

[Bill Hartner]

Rik van Riel wrote:
> 
> On Tue, 17 Sep 2002, Andrew Morton wrote:
> > Bill Hartner wrote:
> > >
> > > I ran VolanoMark 2.1.2 under memory pressure to test rmap.
> > >                              ---------------

> > > 2.5.26 vs 2.5.26 + rmap patch
> > > -----------------------------
> > > It appears as though the page stealing decisions made when using the
> > > 2.5.26 rmap patch may not be as good as the baseline for this workload.
> > > There was more swap activity and idle time.
> >
> > Do you have similar results for 2.4 and 2.4-rmap?
> 
> If Bill is going to test this, I'd appreciate it if he could use
> rmap14a (or newer, if I've released it by the time he gets around
> to testing).
> 

Rik,

I will baseline on 2.4.19 and run both the 3GB and 4GB VoloanoMark test.

I will also test with rmap14a.

I am currently running (a) rawio on scsi devices and (b) direct io on scsi
devices for both read and readv on 2.5.35.  For this test, I am using an
8-way 700 Mhz with (4) IBM 4Mx controllers and 32 disks.

I should be able to get to the 2.4.19 VolanoMark tests by the end of the week.
Both rawio and VolanoMark test use the same machine.

Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35,and 2.5.35 + mm1

[Rik van Riel]

On Wed, 18 Sep 2002, Bill Hartner wrote:

> I will baseline on 2.4.19 and run both the 3GB and 4GB VoloanoMark test.
>
> I will also test with rmap14a.

I released rmap14b last night, with an SMP bugfix you'll want to have:

	http://surriel.com/patches/2.4/2.4.19-rmap14b

> I am currently running (a) rawio on scsi devices and (b) direct io on scsi
> devices for both read and readv on 2.5.35.  For this test, I am using an
> 8-way 700 Mhz with (4) IBM 4Mx controllers and 32 disks.

Hmmm, with near certainty rmap in 2.4 still has a bunch of SMP
inefficiencies that'll slow you down on an 8-way. If these are
bothering you I'll do a backport of the 2.5 rmap speedups...

regards,

Rik
-- 
Spamtrap of the month: september@surriel.com

http://www.surriel.com/		http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [Lse-tech] Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35,and2.5.35 + mm1

[Bill Hartner]

Rik van Riel wrote:
> 
> On Wed, 18 Sep 2002, Bill Hartner wrote:
> 
> > I will baseline on 2.4.19 and run both the 3GB and 4GB VoloanoMark test.
> >
> > I will also test with rmap14a.
> 
> I released rmap14b last night, with an SMP bugfix you'll want to have:
> 
>         http://surriel.com/patches/2.4/2.4.19-rmap14b
> 
> > I am currently running (a) rawio on scsi devices and (b) direct io on scsi
> > devices for both read and readv on 2.5.35.  For this test, I am using an
> > 8-way 700 Mhz with (4) IBM 4Mx controllers and 32 disks.
> 
> Hmmm, with near certainty rmap in 2.4 still has a bunch of SMP
> inefficiencies that'll slow you down on an 8-way. If these are
> bothering you I'll do a backport of the 2.5 rmap speedups...

I have not ran on a UP with memory pressure - could try that.

VolanoMark has looooooong run queues - so I will look for a o(1) 
scheduler patch to lay down and then rmap14b - do you see any problem
with rmap14b on top of o(1) ?

Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35,and 2.5.35 + mm1

[Bill Hartner]

Rik van Riel wrote:
> 
> 
> > > 2.5.26 vs 2.5.26 + rmap patch
> > > -----------------------------
> > > It appears as though the page stealing decisions made when using the
> > > 2.5.26 rmap patch may not be as good as the baseline for this workload.
> > > There was more swap activity and idle time.
> >
> > Do you have similar results for 2.4 and 2.4-rmap?
> 
> If Bill is going to test this, I'd appreciate it if he could use
> rmap14a (or newer, if I've released it by the time he gets around
> to testing).
> 

More VolanoMark results using an 8-way 700 Mhz under memory pressure for
2.4.19 and rmap14b.

Details of SUT same as :

http://marc.theaimsgroup.com/?l=linux-mm&m=103229747000714&w=2

NOTE : the swap device is on ServeRAID which is probably bouncing for
the HIGHMEM pages in most if not all of the tests so results will
likely improve when bouncing is eliminated.

2419     = 2.4.19 + o(1) scheduler
2419rmap = 2.4.19 + rmap14b + o(1) scheduler

%sys/%user = ratio of %system CPU utilization to %user CPU utilization.

========================================
The results for the 3 GB mem test were :
========================================

kernel       msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
-----------  -----  ---- ----------  ------------  ------------  ------------

2.4.19       ***** system hard hangs - requires reset. *****
2.4.19rmap   37767  76.9 1.46        2,274,380 KB  3,800,336 KB  6,074,716 KB

=============================== old data below===============================
2.5.26       51824  96.3 1.42        1,987,024 KB  2,148,100 KB  4,135,124 KB
2.5.26rmap   46053  90.8 1.55        3,139,324 KB  3,887,368 KB  7,026,692 KB
2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB

* used pgin/pgout instead of swapin/swapout since /proc/stat changed.

2.4.19 + o(1) hangs the system - requires reset.

2.4.19 + rmap13 + o(1) performance is degraded.  The baseline 2.4.19 hangs
after a couple of attempts so no direct comparision.  There are also peaks
of idle time during high swap activity.

========================================
The results for the 4 GB mem test were :
========================================

kernel       msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
-----------  -----  ---- ----------  ------------  ------------  ------------

2.4.19       55386  99.8 1.40        0             0             0
2.4.19rmap   52330  99.5 1.43        0             2,363,388 KB  2,363,388 KB

=============================== old data below===============================
2.5.26       55446  99.4 1.40        0             0             0
2.5.35       52845  99.9 1.38        0             0             0
2.5.35mm1    52755  99.9 1.42        0             0             0

2.4.19 + o(1) using 4GB memory performs as well as 2.5.26.

2.4.19 + rmap14b + o(1) performance is down 5.5 % (52330/55386).
There was swap io even though we had 500MB free mem.

Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35,and 2.5.35 + mm1

[Andrew Morton]

Bill Hartner wrote:
> 
> ...
> 2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> 2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> 

2.5.35 was fairly wretched from the swapout point of view.
Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.

(This always happens, sorry.  But stuff is changing fast)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35 + mm1, and 2.5.38 + mm3

[Bill Hartner]

Andrew Morton wrote:
> 
> Bill Hartner wrote:
> >
> > ...
> > 2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> > 2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> >
> 
> 2.5.35 was fairly wretched from the swapout point of view.
> Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.
> 

Here are VolanoMark results for 2.5.38 and 2.5.38-mm3 for both
3GB (memory pressure) and 4GB.  I will repeat for 2.5.40 mm1 or
what ever is the latest and greatest on Friday.

SUT same as :

http://marc.theaimsgroup.com/?l=linux-mm&m=103229747000714&w=2

NOTE : the swap device is on ServeRAID which is probably bouncing for
the HIGHMEM pages in most if not all of the tests so results will
likely improve when bouncing is eliminated.  Need to work this problem next.

2419     = 2.4.19 + o(1) scheduler
2419rmap = 2.4.19 + rmap14b + o(1) scheduler

%sys/%user = ratio of %system CPU utilization to %user CPU utilization.

========================================
The results for the 3 GB mem test were :
========================================

kernel       msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
-----------  -----  ---- ----------  ------------  ------------  ------------

2.5.38       46081  90.1 1.44        1,992,608 KB  2,881,056 KB  4,873,664 KB
2.5.38mm3    44950  99.8 1.52        did not collect io - /proc/stat changed

=============================== old data below===============================
2.4.19       ***** system hard hangs - requires reset. *****
2.4.19rmap   37767  76.9 1.46        2,274,380 KB  3,800,336 KB  6,074,716 KB
2.5.26       51824  96.3 1.42        1,987,024 KB  2,148,100 KB  4,135,124 KB
2.5.26rmap   46053  90.8 1.55        3,139,324 KB  3,887,368 KB  7,026,692 KB
2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB

* used pgin/pgout instead of swapin/swapout since /proc/stat changed.

2.5.38 does not perform as well as 2.5.26 (before rmap).
46081/51284 = 89.9 % or 10.1 % degradation.

2.5.38mm3 does not perform as well as 2.5.38.
44950/46081 = 97.5 % or 2.5 % degradation.
CPU utilization is also higher - 99.8 vs 90.1.

========================================
The results for the 4 GB mem test were :
========================================

kernel       msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
-----------  -----  ---- ----------  ------------  ------------  ------------

2.5.38       53084  99.9 1.41        0             0             0
2.5.38mm3    49933  99.9 1.47        0             0             0

=============================== old data below===============================
2.4.19       55386  99.8 1.40        0             0             0
2.4.19rmap   52330  99.5 1.43        0             2,363,388 KB  2,363,388 KB
2.5.26       55446  99.4 1.40        0             0             0
2.5.35       52845  99.9 1.38        0             0             0
2.5.35mm1    52755  99.9 1.42        0             0             0

2.5.38 does not perform as well as 2.5.26.
53084/55426 = 95.8 % or 4.2 % degradation.

2.5.38mm3 does not perform as well as 2.5.38.
49933/53084 = 94.1 % or 5.9 % degradation. Higher ratio of system CPU.

Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35 + mm1, and 2.5.38 + mm3

[Andrew Morton]

Bill Hartner wrote:
> 
> Andrew Morton wrote:
> >
> > Bill Hartner wrote:
> > >
> > > ...
> > > 2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> > > 2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> > >
> >
> > 2.5.35 was fairly wretched from the swapout point of view.
> > Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.
> >
> 
> Here are VolanoMark results for 2.5.38 and 2.5.38-mm3 for both
> 3GB (memory pressure) and 4GB.  I will repeat for 2.5.40 mm1 or
> what ever is the latest and greatest on Friday.

Thanks again.

> SUT same as :
> 
> http://marc.theaimsgroup.com/?l=linux-mm&m=103229747000714&w=2
> 
> NOTE : the swap device is on ServeRAID which is probably bouncing for
> the HIGHMEM pages in most if not all of the tests so results will
> likely improve when bouncing is eliminated.  Need to work this problem next.
> 
> 2419     = 2.4.19 + o(1) scheduler
> 2419rmap = 2.4.19 + rmap14b + o(1) scheduler
> 
> %sys/%user = ratio of %system CPU utilization to %user CPU utilization.
> 
> ========================================
> The results for the 3 GB mem test were :
> ========================================
> 
> kernel       msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
> -----------  -----  ---- ----------  ------------  ------------  ------------
> 
> 2.5.38       46081  90.1 1.44        1,992,608 KB  2,881,056 KB  4,873,664 KB
> 2.5.38mm3    44950  99.8 1.52        did not collect io - /proc/stat changed

That's probably due to the more aggressive promote-reads-before-writes
tuning.  The same is observable with the `qsbench' benchmark.

> =============================== old data below===============================
> 2.4.19       ***** system hard hangs - requires reset. *****
> 2.4.19rmap   37767  76.9 1.46        2,274,380 KB  3,800,336 KB  6,074,716 KB
> 2.5.26       51824  96.3 1.42        1,987,024 KB  2,148,100 KB  4,135,124 KB
> 2.5.26rmap   46053  90.8 1.55        3,139,324 KB  3,887,368 KB  7,026,692 KB
> 2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> 2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> 
> * used pgin/pgout instead of swapin/swapout since /proc/stat changed.
> 
> 2.5.38 does not perform as well as 2.5.26 (before rmap).
> 46081/51284 = 89.9 % or 10.1 % degradation.
> 
> 2.5.38mm3 does not perform as well as 2.5.38.
> 44950/46081 = 97.5 % or 2.5 % degradation.
> CPU utilization is also higher - 99.8 vs 90.1.

Yes, we're generally more eager to start swapout.
 
> ========================================
> The results for the 4 GB mem test were :
> ========================================
> 
> kernel       msg/s  %CPU %sys/%user  Total swpin   Total swpout  Total swapio
> -----------  -----  ---- ----------  ------------  ------------  ------------
> 
> 2.5.38       53084  99.9 1.41        0             0             0
> 2.5.38mm3    49933  99.9 1.47        0             0             0
> 
> =============================== old data below===============================
> 2.4.19       55386  99.8 1.40        0             0             0
> 2.4.19rmap   52330  99.5 1.43        0             2,363,388 KB  2,363,388 KB
> 2.5.26       55446  99.4 1.40        0             0             0
> 2.5.35       52845  99.9 1.38        0             0             0
> 2.5.35mm1    52755  99.9 1.42        0             0             0
> 
> 2.5.38 does not perform as well as 2.5.26.
> 53084/55426 = 95.8 % or 4.2 % degradation.
> 
> 2.5.38mm3 does not perform as well as 2.5.38.
> 49933/53084 = 94.1 % or 5.9 % degradation. Higher ratio of system CPU.

Davem says that the loopback network device is currently doing an
extra copy, which will go away soon.  (That was news to me).

I wonder if volanomark does tcp to localhost?  `ifconfig lo' will
tell us.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [Lse-tech] Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35 + mm1, and 2.5.38 + mm3

[Dave Hansen]

Bill Hartner wrote:
> Andrew Morton wrote:
> 
>>Bill Hartner wrote:
>>
>>>...
>>>2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
>>>2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
>>>
>>
>>2.5.35 was fairly wretched from the swapout point of view.
>>Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.
>>
> 
> Here are VolanoMark results for 2.5.38 and 2.5.38-mm3 for both
> 3GB (memory pressure) and 4GB.  I will repeat for 2.5.40 mm1 or
> what ever is the latest and greatest on Friday.

Could you possibly include profiling data as well?  oprofile would be 
preferred, but readprofile would be fine if you can get it.  We can 
guess what is causing the degredation, but profiles will offer some 
hard proof.

-- 
Dave Hansen
haveblue@us.ibm.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [Lse-tech] Re: VolanoMark Benchmark results for 2.5.26, 2.5.26 + rmap, 2.5.35 +mm1, and 2.5.38 + mm3

[Andrew Morton]

Andrew Morton wrote:
> 
> ...
> I wonder if volanomark does tcp to localhost?  `ifconfig lo' will
> tell us.

OK, I googled up some kernel profiles.  Volanomark does
tcp to localhost.

We'll need kernel profiles to take this further.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [Lse-tech] Re: VolanoMark Benchmark results for 2.5.26, 2.5.26+ rmap, 2.5.35 + mm1, and 2.5.38 + mm3

[Bill Hartner]

Dave Hansen wrote:
> 
> Bill Hartner wrote:
> > Andrew Morton wrote:
> >
> >>Bill Hartner wrote:
> >>
> >>>...
> >>>2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> >>>2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> >>>
> >>
> >>2.5.35 was fairly wretched from the swapout point of view.
> >>Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.
> >>
> >
> > Here are VolanoMark results for 2.5.38 and 2.5.38-mm3 for both
> > 3GB (memory pressure) and 4GB.  I will repeat for 2.5.40 mm1 or
> > what ever is the latest and greatest on Friday.
> 
> Could you possibly include profiling data as well?  oprofile would be
> preferred, but readprofile would be fine if you can get it.  We can
> guess what is causing the degredation, but profiles will offer some
> hard proof.

I will get 2.5.40 mm1 results and then get a profile before and after the
point that we start swapping.

I think that the ips driver may be bouncing here - so I would like to
resolve that 1st - could change results - possibly quite a bit.

Bill

> 
> --
> Dave Hansen
> haveblue@us.ibm.com

-- 
IBM Linux Technology Center Performance Team
bhartner@austin.ibm.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [Lse-tech] Re: VolanoMark Benchmark results for 2.5.26, 2.5.26+ rmap, 2.5.35 + mm1, and 2.5.38 + mm3

[Andrew Morton]

Bill Hartner wrote:
> 
> Dave Hansen wrote:
> >
> > Bill Hartner wrote:
> > > Andrew Morton wrote:
> > >
> > >>Bill Hartner wrote:
> > >>
> > >>>...
> > >>>2.5.35       44693  86.1 1.45        1,982,236 KB  5,393,152 KB  7,375,388 KB
> > >>>2.5.35mm1    39679  99.6 1.50       *2,720,600 KB *6,154,512 KB *8,875,112 KB
> > >>>
> > >>
> > >>2.5.35 was fairly wretched from the swapout point of view.
> > >>Would be interesting to retest on 2.5.38-mm/2.5.39 sometime.
> > >>
> > >
> > > Here are VolanoMark results for 2.5.38 and 2.5.38-mm3 for both
> > > 3GB (memory pressure) and 4GB.  I will repeat for 2.5.40 mm1 or
> > > what ever is the latest and greatest on Friday.
> >
> > Could you possibly include profiling data as well?  oprofile would be
> > preferred, but readprofile would be fine if you can get it.  We can
> > guess what is causing the degredation, but profiles will offer some
> > hard proof.
> 
> I will get 2.5.40 mm1 results and then get a profile before and after the
> point that we start swapping.
> 
> I think that the ips driver may be bouncing here - so I would like to
> resolve that 1st - could change results - possibly quite a bit.
> 

Profiles will tell.

Bill, I'd recommend that you simply *always* generate a kernel profile.
Just make it a part of the routine.  They tell us so much.

It's a matter of replacing

	test

with

	readprofile -r
	test
	readprofile -v -m /boot/System.map | sort -n +2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/