| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20080320181757.737af9b4@cuia.boston.redhat.com> Date: Thu, 20 Mar 2008 18:17:57 -0400 From: Rik van Riel <riel@...hat.com> To: Brian Harring <ferringb@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: fsync/MAP_SHARED slowdown On Thu, 20 Mar 2008 13:12:16 -0700 Brian Harring <ferringb@...il.com> wrote: > Back in 09/2006, rev d08b3851da41d0ee60851f2c75b118e1f7a5fc89 > (discussion at http://lkml.org/lkml/2006/6/19/245) was commited with > the purpose enabling tracking of shared dirty pages. > > Still trying to identify exactly why, but that specific rev results in > a ~3x slowdown in fsync speed for an app of ours- an isolated test > case demonstrating it is attached. The kernel now includes an implicit msync for each fsync. In short, before the change an fsync would not find all the dirty pages of the file, because some of the dirty bits might be "hiding" in the page tables, while the current kernel actually finds those dirty bits and writes all dirty data to disk. Would you rather have the fast fsync, or the one that actually writes all the dirty data to disk? :) -- All Rights Reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists