public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Linux 2.6.24 Through Linux 2.6.33 Benchmarks
@ 2010-03-10 18:34 Anca Emanuel
  2010-03-11 19:27 ` Paolo Ornati
  0 siblings, 1 reply; 2+ messages in thread
From: Anca Emanuel @ 2010-03-10 18:34 UTC (permalink / raw)
  To: linux-kernel; +Cc: torvalds

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Linux 2.6.24 Through Linux 2.6.33 Benchmarks
  2010-03-10 18:34 Linux 2.6.24 Through Linux 2.6.33 Benchmarks Anca Emanuel
@ 2010-03-11 19:27 ` Paolo Ornati
  0 siblings, 0 replies; 2+ messages in thread
From: Paolo Ornati @ 2010-03-11 19:27 UTC (permalink / raw)
  To: Anca Emanuel; +Cc: linux-kernel, torvalds

On Wed, 10 Mar 2010 20:34:12 +0200
Anca Emanuel <anca.emanuel@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@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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-03-11 19:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-10 18:34 Linux 2.6.24 Through Linux 2.6.33 Benchmarks Anca Emanuel
2010-03-11 19:27 ` Paolo Ornati

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox