Messages in this thread | | | Date | Fri, 8 Jun 2001 14:50:22 +0200 (CEST) | From | Mike Galbraith <> | Subject | Re: VM Report was:Re: Break 2.4 VM in five easy steps |
| |
On Fri, 8 Jun 2001, Jonathan Morton wrote:
> http://www.chromatix.uklinux.net/linux-patches/vm-update-2.patch > > Try this. I can't guarantee it's SMP-safe yet (I'm leaving the gurus to > that, but they haven't told me about any errors in the past hour so I'm > assuming they aren't going to find anything glaringly wrong...), but you > might like to see if your performance improves with it. It also fixes the > OOM-killer bug, which you refer to above. > > Some measurements, from my own box (1GHz Athlon, 256Mb RAM): > > For the following benchmarks, physical memory availability was reduced > according to the parameter in the left column. The benchmark is the > wall-clock time taken to compile MySQL. > > mem= 2.4.5 earlier tweaks now > 48M 8m30s 6m30s 5m58s > 32M unknown 2h15m 12m34s > > The following was performed with all 256Mb RAM available. This is > compilation of MySQL using make -j 15. > > kernel: 2.4.5 now > time: 6m30s 6m15s > peak swap: 190M 70M > > For the following test, the 256Mb swap partition on my IDE drive was > disabled and replaced with a 1Gb swapfile on my Ultra160 SCSI drive. This > is compilation of MySQL using make -j 20. > > kernel: 2.4.5 now > time: 7m20s 6m30s > peak swap: 370M 254M > > Draw your own conclusions. :)
(ok;)
Hi,
I gave this a shot at my favorite vm beater test (make -j30 bzImage) while testing some other stuff today.
seven identical runs, six slightly different kernels plus yours.
real 11m23.522s 2.4.5.vm-update-2 user 7m59.170s sys 0m37.030s user : 0:08:07.06 65.6% page in : 642402 nice : 0:00:00.00 0.0% page out: 676820 system: 0:02:09.44 17.4% swap in : 105965 idle : 0:02:05.66 16.9% swap out: 162603
real 10m9.512s 2.4.5.virgin user 7m55.520s sys 0m35.460s user : 0:08:02.66 72.2% page in : 535186 nice : 0:00:00.00 0.0% page out: 377992 system: 0:01:37.78 14.6% swap in : 99445 idle : 0:01:28.14 13.2% swap out: 81926
real 10m48.939s 2.4.5.virgin+reclaim.marcelo user 7m54.960s sys 0m36.240s user : 0:08:02.33 68.0% page in : 566239 nice : 0:00:00.00 0.0% page out: 431874 system: 0:01:56.02 16.4% swap in : 108633 idle : 0:01:50.61 15.6% swap out: 96415
real 9m54.466s 2.4.5.virgin+reclaim.mike (icky 'bleeder valve') user 7m57.370s sys 0m35.890s user : 0:08:04.74 74.1% page in : 527678 nice : 0:00:00.00 0.0% page out: 405259 system: 0:01:12.01 11.0% swap in : 98616 idle : 0:01:37.47 14.9% swap out: 91492
real 9m12.198s 2.4.5.tweak user 7m41.290s sys 0m34.840s user : 0:07:47.69 76.8% page in : 452632 nice : 0:00:00.00 0.0% page out: 399847 system: 0:01:17.08 12.7% swap in : 75338 idle : 0:01:03.97 10.5% swap out: 88291
real 9m41.563s 2.4.5.tweak+reclaim.marcelo user 7m59.880s sys 0m34.690s user : 0:08:07.22 73.4% page in : 515433 nice : 0:00:00.00 0.0% page out: 545762 system: 0:01:35.34 14.4% swap in : 88425 idle : 0:01:21.11 12.2% swap out: 125967
real 9m47.682s 2.4.5.tweak+reclaim.mike user 8m2.190s sys 0m34.550s user : 0:08:09.57 75.7% page in : 513166 nice : 0:00:00.00 0.0% page out: 473539 system: 0:01:20.27 12.4% swap in : 83127 idle : 0:01:16.89 11.9% swap out: 108886
Conclusion:
Your patch hits the cache too hard and pays through the nose for doing so.. at least under this hefty weight load it does.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |