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]
Date:   Thu, 22 Jun 2017 01:07:48 +0800
From:   Sean Fu <fxinrong@...il.com>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     shli@...nel.org, anton@...era.com, jack@...e.cz, axboe@...com,
        ebiggers@...gle.com, rpeterso@...hat.com, bmarzins@...hat.com,
        linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-ntfs-dev@...ts.sourceforge.net
Subject: Re: [PATCH] fs: buffer: Modify alloc_page_buffers.

On Mon, Jun 19, 2017 at 05:03:16PM +0100, Al Viro wrote:
> On Mon, Jun 19, 2017 at 09:01:36PM +0800, Sean Fu wrote:
> > Make alloc_page_buffers support circular buffer list and initialise
> > b_state field.
> > Optimize the performance by removing the buffer list traversal to create
> > circular buffer list.
> 
> > -		bh = head = alloc_page_buffers(page, blocksize, 1);
> > +		bh = head = alloc_page_buffers(page, blocksize, 1, 0, 0);
> 
> Frankly, I don't like that change of calling conventions; it's very easy to
> mess the order of arguments when using interfaces like that and it's hell
> to find when trying to debug the resulting mess.
> 
> Do you really get an observable change in performance?  What loads are
> triggering it?
Yes, I have got the performance change with ext3 file system which block
size is 1024 bytes. It has at least %5 performance improvement.

I have found the performance improvements when writting/reading a 800M
size of file on ext3 file system with 1024 block size.
In this case, Each page has four buffer. In other word, the buffer list
has 4 elements.

I have compared the time that the process spent in kernel mode.

Improvements via this patch
Before		After
Write:
0m5.604s	0m4.116s
0m4.408s	0m3.924s
0m4.184s	0m3.708s
0m4.352s	0m3.656s
0m4.380s	0m3.608s
0m4.240s	0m3.612s
0m4.460s	0m3.552s
0m4.072s	0m3.832s
0m4.300s	0m3.736s
0m4.400s	0m3.480s

Read:
0m3.128s	0m3.036s
0m2.976s	0m2.568s
0m3.384s	0m2.544s
0m3.112s	0m2.752s
0m2.924s	0m2.684s
0m3.084s	0m2.856s
0m3.348s	0m2.576s
0m3.000s	0m2.968s
0m3.012s	0m2.560s
0m2.768s	0m2.752s

Reproduce steps:
1 mkfs.ext3 -b 1024 /dev/sdb1
2 ./test_write.sh ./writetest 10

Test shell script:
#!/bin/bash
i=$2;
while test $((i)) -ge 1; do
	mount /dev/sdb1 /mnt/sdb1/
	time $1 -b 800 -o /mnt/sdb1/fileout
	rm /mnt/sdb1/fileout
	sync
	sleep 1
	umount /mnt/sdb1/
	echo "aaa"
	i=$i-1
done


The attachment are the code for writetest and test result.

View attachment "writetest.c" of type "text/x-c" (7610 bytes)

View attachment "patched_data.txt" of type "text/plain" (4202 bytes)

View attachment "no_patched_data.txt" of type "text/plain" (4060 bytes)

Powered by blists - more mailing lists