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: <20130911101122.GA2167@quack.suse.cz> Date: Wed, 11 Sep 2013 12:11:22 +0200 From: Jan Kara <jack@...e.cz> To: Bernd Schubert <bernd.schubert@...m.fraunhofer.de> Cc: Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>, linux-ext4@...r.kernel.org, Yan Zheng <ukernel@...il.com>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org> Subject: Re: [PATCH] ext4: Fix performance regression in writeback of random writes On Wed 11-09-13 11:45:03, Bernd Schubert wrote: > On 09/10/2013 09:40 PM, Jan Kara wrote: > >Linux Kernel Performance project guys have reported that commit 4e7ea81db5 > >introduces a performance regression for the following fio workload: > >[global] > >direct=0 > >ioengine=mmap > >size=1500M > >bs=4k > >pre_read=1 > >numjobs=1 > >overwrite=1 > >loops=5 > >runtime=300 > >group_reporting > >invalidate=0 > >directory=/mnt/ > >file_service_type=random:36 > >file_service_type=random:36 > > > >[job0] > >startdelay=0 > >rw=randrw > >filename=data0/f1:data0/f2 > > > >[job1] > >startdelay=0 > >rw=randrw > >filename=data0/f2:data0/f1 > >... > > > >[job7] > >startdelay=0 > >rw=randrw > >filename=data0/f2:data0/f1 > > > >The culprit of the problem is that after the commit ext4_writepages() > >are more aggressive in writing back pages. Thus we have less consecutive > >dirty pages resulting in more seeking. > > > >This increased aggressivity is caused by a bug in the condition > >terminating ext4_writepages(). We start writing from the beginning of > >the file even if we should have terminated ext4_writepages() because > >wbc->nr_to_write <= 0. > > > >After fixing the condition the throughput of the fio workload is about 20% > >better than before writeback reorganization. > > > >Reported-by: "Yan, Zheng" <zheng.z.yan@...el.com> > >Signed-off-by: Jan Kara <jack@...e.cz> > >--- > > fs/ext4/inode.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > >index c79fd7d..7914c05 100644 > >--- a/fs/ext4/inode.c > >+++ b/fs/ext4/inode.c > >@@ -2563,7 +2563,7 @@ retry: > > break; > > } > > blk_finish_plug(&plug); > >- if (!ret && !cycled) { > >+ if (!ret && !cycled && wbc->nr_to_write > 0) { > > cycled = 1; > > mpd.last_page = writeback_index - 1; > > mpd.first_page = 0; > > > > Interesting, doesn't that mean generic_writepages (sub-sequent > write_cache_pages() ) and all other file systems implementing their > own ->writepages() should be updated? No. write_cache_pages() has the condition like: if (!cycled && !done) { and 'done' is set when wbc->nr_to_write drops to zero. So that function is OK. We cannot use 'done' in ext4_writepages() because the functions are structured a bit differently and 'done' gets set also when reach end of file. Honza -- Jan Kara <jack@...e.cz> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists