linux-kernel - Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090130012315.GB19554@duck.suse.cz>
Date:	Fri, 30 Jan 2009 02:23:15 +0100
From:	Jan Kara <jack@...e.cz>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	npiggin@...e.de
Subject: Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down
	Berkeley DB

  Hi,

  today I found that commit 31a12666d8f0c22235297e1c1575f82061480029 (mm:
write_cache_pages cyclic fix) slows down operations over Berkeley DB.
Without this "fix", I can add 100k entries in about 5 minutes 30s, with
that change it takes about 20 minutes. 
  What is IMO happening is that previously we scanned to the end of file,
we left writeback_index at the end of file and went to write next file.
With the fix, we wrap around (seek) and after writing some more we go
to next file (seek again).
  Anyway, I think the original semantics of "cyclic" makes more sence, just
the name was chosen poorly. What we should do is really scan to the end of
file, reset index to start from the beginning next time and go for the next
file.
  I can write a patch to introduce this semantics but I'd like to hear
opinions of other people before I do so.

									Honza

-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/