Linux 2.6.24 Through Linux 2.6.33 Benchmarks
in [Kernel]
|
Prev: Kernel memory leak warning due to KDED4
Next: call_usermodehelper: call info->init() after set_user_nice()
From: Anca Emanuel on 10 Mar 2010 13:40 Linux 2.6.24 Through Linux 2.6.33 Benchmarks http://www.phoronix.com/scan.php?page=article&item=linux_2624_2633&num=1 quote: "This test system was using the EXT3 file-system and we found its TPC-B database performance to improve by many times between the Linux 2.6.29 and 2.6.30 kernel releases. In fact, the Linux 2.6.30 kernel was 770% faster than its predecessor was and it remained that way with the Linux 2.6.31 kernel and then regressed only slightly with the Linux 2.6.32 kernel. With the new Linux 2.6.33 kernel, however, the PostgreSQL performance atop the EXT3 file-system has fallen off a cliff. Not only has the PostgreSQL performance lost its gains made during the 2.6.30 development cycle, but also with Linux 2.6.33, it is actually much slower than it was in any of the pre-2.6.30 releases." http://www.phoronix.com/data/img/results/linux_2624_2633/2.png -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paolo Ornati on 11 Mar 2010 14:30
On Wed, 10 Mar 2010 20:34:12 +0200 Anca Emanuel <anca.emanuel(a)gmail.com> wrote: > In fact, the Linux 2.6.30 kernel > was 770% faster than its predecessor was and it remained that way with > the Linux 2.6.31 kernel and then regressed only slightly with the > Linux 2.6.32 kernel. With the new Linux 2.6.33 kernel, however, the > PostgreSQL performance atop the EXT3 file-system has fallen off a > cliff. The extra performance was just a "bug": http://www.mail-archive.com/pgsql-performance(a)postgresql.org/msg34841.html "[This change] is required for safe behavior with volatile write caches on drives. You could mount with -o nobarrier and [the performance drop] would go away, but a sequence like write->fsync->lose power->reboot may well find your file without the data that you synced, if the drive had write caches enabled. If you know you have no write cache, or that it is safely battery backed, then you can mount with -o nobarrier, and not incur this penalty." -- Paolo Ornati Linux 2.6.33-00001-gbaac35c on x86_64 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |