linux-ext4 - RE: [PATCH 1/2] ext4: introduce new i_write

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-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <000c01cf7c9b$edaf2f90$c90d8eb0$@samsung.com>
Date:	Sat, 31 May 2014 15:45:36 +0900
From:	Namjae Jeon <namjae.jeon@...sung.com>
To:	'Theodore Ts'o' <tytso@....edu>,
	'Lukáš Czerner' <lczerner@...hat.com>
Cc:	'linux-ext4' <linux-ext4@...r.kernel.org>,
	'Ashish Sangwan' <a.sangwan@...sung.com>
Subject: RE: [PATCH 1/2] ext4: introduce new i_write_mutex to protect fallocate

> 
> On Thu, May 29, 2014 at 02:42:04PM +0200, Lukáš Czerner wrote:
> >
> > I wonder what is the performance impact of this change ? Especially
> > since we're not longer taking the lock only in unaligned aio/dio
> > case but in all cases ?
> 
> Thinking about this some more, this is also going to break parallel
> writes, which would be unfortunate.  We might want to change this to
> using a rw mutex, where writes take a shared lock, and require
> fallocate to take an exclusive lock....
ext4 file write is already serialized with inode mutex.
So I think the impact of adding another lock will be very very less..
When I run parallel write test of fio to prove it, I can not see the difference on w/wo i_write_mutex.

[job1]
ioengine=sync
buffered=1
rw=write
numjobs=100
filename=file1
rw_sequencer=sequential
size=10485760000
filesize=104857600
nrfiles=1
openfiles=100

Without i_write_mutex =>
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=276869KB/s, minb=2768KB/s, maxb=3530KB/s, mint=29007msec, maxt=36985msec
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=273862KB/s, minb=2738KB/s, maxb=3584KB/s, mint=28566msec, maxt=37391msec
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=271373KB/s, minb=2713KB/s, maxb=3650KB/s, mint=28048msec, maxt=37734msec
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=274906KB/s, minb=2749KB/s, maxb=3554KB/s, mint=28808msec, maxt=37249msec

With i_write_mutex patch applied =>
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=273672KB/s, minb=2736KB/s, maxb=3498KB/s, mint=29269msec, maxt=37417msec
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=271877KB/s, minb=2718KB/s, maxb=3401KB/s, mint=30101msec, maxt=37664msec
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=272753KB/s, minb=2727KB/s, maxb=3412KB/s, mint=30008msec, maxt=37543msec
Run status group 0 (all jobs):
  WRITE: io=10000MB, aggrb=274508KB/s, minb=2745KB/s, maxb=3267KB/s, mint=31335msec, maxt=37303msec

Yes, Right. We can use shared lock to remove a little bit lock contention in ext4 file write.
I will share rwsem lock patch.. Could you please revert i_write_mutex patch ?

Thanks!

> 
> 				- Ted

--
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