linux-ext4 - Re: bio splits unnecessarily due to BH

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: <20130329171536.GF5913@quack.suse.cz>
Date:	Fri, 29 Mar 2013 18:15:36 +0100
From:	Jan Kara <jack@...e.cz>
To:	Kazuya Mio <k-mio@...jp.nec.com>
Cc:	Jan Kara <jack@...e.cz>, akpm@...ux-foundation.org,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: bio splits unnecessarily due to BH_Boundary in ext3 direct I/O

On Thu 21-03-13 17:43:52, Kazuya Mio wrote:
> 2013/03/20 4:31, Jan Kara wrote:
> >  I'm not sure I understand. Looking into dio_send_cur_page() it seems may
> >prematurely submit the bio if sdio->boundary is set - in that case we
> >should probably first try to add the page to the bio and submit the bio
> >only after that. Is that what you mean?
> 
> I think the direct I/O works for each page into buffer_head by the following
> three steps:
> 1. submit sdio->bio if sdio->boudary is set
> 2. add sdio->cur_page to sdio->bio by dio_new_bio() or dio_bio_add_page()
> 3. set the curret page to sdio->cur_page in submit_page_section()
> 
> It is true that dio_send_cur_page() submits the bio if sdio->boudary is set.
> However, at this time, this bio does not contain sdio->cur_page and
> the current page do_direct_IO() passed.
  Sorry for not getting to you earlier. So we agree in our analysis. Do you
agree with the attached patch? Does it help your workload?

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR

View attachment "0001-direct-io-Submit-bio-after-boundary-buffer-is-added-.patch" of type "text/x-patch" (1552 bytes)