linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC
@ 2016-08-27  0:53 Jaegeuk Kim
  2016-09-02  7:33 ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Jaegeuk Kim @ 2016-08-27  0:53 UTC (permalink / raw)
  To: linux-kernel, linux-fsdevel, linux-f2fs-devel; +Cc: Jaegeuk Kim

This can avoid bio splits due to different op_flags.

Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
 fs/f2fs/data.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 7c8e219..c7c2022 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -267,6 +267,11 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
 
 	down_write(&io->io_rwsem);
 
+	/* WRITE can be merged into previous WRITE_SYNC */
+	if (io->bio && io->last_block_in_bio == fio->new_blkaddr - 1 &&
+			io->fio.op == fio->op && io->fio.op_flags == WRITE_SYNC)
+		fio->op_flags = WRITE_SYNC;
+
 	if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
 	    (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
 		__submit_merged_bio(io);
-- 
2.8.3

^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC
  2016-08-27  0:53 [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC Jaegeuk Kim
@ 2016-09-02  7:33 ` Chao Yu
  2016-09-02 18:36   ` Jaegeuk Kim
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2016-09-02  7:33 UTC (permalink / raw)
  To: Jaegeuk Kim, linux-kernel, linux-fsdevel, linux-f2fs-devel

Hi Jaegeuk,

On 2016/8/27 8:53, Jaegeuk Kim wrote:
> This can avoid bio splits due to different op_flags.

I thought about this, but I think this is not a good idea to increase merging
ratio of pages in bio. It breaks the rule of SYNC/ASYNC IO defined by system
which indicate degree of IO emergency, finally, some/more non-emergent IO will
treated as emergent one by IO scheduler, it will interrupt SYNC IOs in block
layer, more seriously, it may make real SYNC IO starvation.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  fs/f2fs/data.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 7c8e219..c7c2022 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -267,6 +267,11 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
>  
>  	down_write(&io->io_rwsem);
>  
> +	/* WRITE can be merged into previous WRITE_SYNC */
> +	if (io->bio && io->last_block_in_bio == fio->new_blkaddr - 1 &&
> +			io->fio.op == fio->op && io->fio.op_flags == WRITE_SYNC)
> +		fio->op_flags = WRITE_SYNC;
> +
>  	if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
>  	    (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
>  		__submit_merged_bio(io);
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC
  2016-09-02  7:33 ` Chao Yu
@ 2016-09-02 18:36   ` Jaegeuk Kim
  2016-09-07 14:12     ` [f2fs-dev] " Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Jaegeuk Kim @ 2016-09-02 18:36 UTC (permalink / raw)
  To: Chao Yu; +Cc: linux-kernel, linux-fsdevel, linux-f2fs-devel

On Fri, Sep 02, 2016 at 03:33:33PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> On 2016/8/27 8:53, Jaegeuk Kim wrote:
> > This can avoid bio splits due to different op_flags.
> 
> I thought about this, but I think this is not a good idea to increase merging
> ratio of pages in bio. It breaks the rule of SYNC/ASYNC IO defined by system
> which indicate degree of IO emergency, finally, some/more non-emergent IO will
> treated as emergent one by IO scheduler, it will interrupt SYNC IOs in block
> layer, more seriously, it may make real SYNC IO starvation.

I understand your concern.
Originally, I tried to avoid breaking a big WRITE_SYNC by a small number of
WRITE. And, I thought new WRITE can be piggybacked into previous WRITE_SYNC.

IMO, this happens very occassionally since previous pending bio should be
WRITE_SYNC while a new request is WRITE. Even if this happens, the piggybacked
size would not exceed over bio's max pages.
If lots of WRITE come, we won't change at all.

Thanks,

> 
> Thanks,
> 
> > 
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  fs/f2fs/data.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 7c8e219..c7c2022 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -267,6 +267,11 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
> >  
> >  	down_write(&io->io_rwsem);
> >  
> > +	/* WRITE can be merged into previous WRITE_SYNC */
> > +	if (io->bio && io->last_block_in_bio == fio->new_blkaddr - 1 &&
> > +			io->fio.op == fio->op && io->fio.op_flags == WRITE_SYNC)
> > +		fio->op_flags = WRITE_SYNC;
> > +
> >  	if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
> >  	    (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
> >  		__submit_merged_bio(io);
> > 

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [f2fs-dev] [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC
  2016-09-02 18:36   ` Jaegeuk Kim
@ 2016-09-07 14:12     ` Chao Yu
  2016-09-08  0:26       ` Jaegeuk Kim
  0 siblings, 1 reply; 6+ messages in thread
From: Chao Yu @ 2016-09-07 14:12 UTC (permalink / raw)
  To: Jaegeuk Kim, Chao Yu; +Cc: linux-fsdevel, linux-kernel, linux-f2fs-devel

On 2016/9/3 2:36, Jaegeuk Kim wrote:
> On Fri, Sep 02, 2016 at 03:33:33PM +0800, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2016/8/27 8:53, Jaegeuk Kim wrote:
>>> This can avoid bio splits due to different op_flags.
>>
>> I thought about this, but I think this is not a good idea to increase merging
>> ratio of pages in bio. It breaks the rule of SYNC/ASYNC IO defined by system
>> which indicate degree of IO emergency, finally, some/more non-emergent IO will
>> treated as emergent one by IO scheduler, it will interrupt SYNC IOs in block
>> layer, more seriously, it may make real SYNC IO starvation.
> 
> I understand your concern.
> Originally, I tried to avoid breaking a big WRITE_SYNC by a small number of

Hmm.. I'm worry about the opposite case: user triggers small WRITE_SYNC IO
periodically, meanwhile there are big number of WRITE, with our new approach,
actually we will increase the number of synchronous WRITE IO obviously because
we will mix ASYNC/SYNC WRITE into bio cache intensively more than before since
we drop writepages mutexlock. So I'm afread the result is that it will mislead
scheduling of block layer.

> WRITE. And, I thought new WRITE can be piggybacked into previous WRITE_SYNC.
> 
> IMO, this happens very occassionally since previous pending bio should be
> WRITE_SYNC while a new request is WRITE. Even if this happens, the piggybacked
> size would not exceed over bio's max pages.
> If lots of WRITE come, we won't change at all.

I thinks this is related to writeback / blocklayer / cgroup subsystem which use
this tag frequently, maybe we should Cc their's mailing list for more opinion...

What's your opinion? :)

thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>> ---
>>>  fs/f2fs/data.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 7c8e219..c7c2022 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -267,6 +267,11 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
>>>  
>>>  	down_write(&io->io_rwsem);
>>>  
>>> +	/* WRITE can be merged into previous WRITE_SYNC */
>>> +	if (io->bio && io->last_block_in_bio == fio->new_blkaddr - 1 &&
>>> +			io->fio.op == fio->op && io->fio.op_flags == WRITE_SYNC)
>>> +		fio->op_flags = WRITE_SYNC;
>>> +
>>>  	if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
>>>  	    (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
>>>  		__submit_merged_bio(io);
>>>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [f2fs-dev] [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC
  2016-09-07 14:12     ` [f2fs-dev] " Chao Yu
@ 2016-09-08  0:26       ` Jaegeuk Kim
  2016-09-08 16:09         ` Chao Yu
  0 siblings, 1 reply; 6+ messages in thread
From: Jaegeuk Kim @ 2016-09-08  0:26 UTC (permalink / raw)
  To: Chao Yu; +Cc: Chao Yu, linux-fsdevel, linux-kernel, linux-f2fs-devel

On Wed, Sep 07, 2016 at 10:12:17PM +0800, Chao Yu wrote:
> On 2016/9/3 2:36, Jaegeuk Kim wrote:
> > On Fri, Sep 02, 2016 at 03:33:33PM +0800, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2016/8/27 8:53, Jaegeuk Kim wrote:
> >>> This can avoid bio splits due to different op_flags.
> >>
> >> I thought about this, but I think this is not a good idea to increase merging
> >> ratio of pages in bio. It breaks the rule of SYNC/ASYNC IO defined by system
> >> which indicate degree of IO emergency, finally, some/more non-emergent IO will
> >> treated as emergent one by IO scheduler, it will interrupt SYNC IOs in block
> >> layer, more seriously, it may make real SYNC IO starvation.
> > 
> > I understand your concern.
> > Originally, I tried to avoid breaking a big WRITE_SYNC by a small number of
> 
> Hmm.. I'm worry about the opposite case: user triggers small WRITE_SYNC IO
> periodically, meanwhile there are big number of WRITE, with our new approach,
> actually we will increase the number of synchronous WRITE IO obviously because
> we will mix ASYNC/SYNC WRITE into bio cache intensively more than before since
> we drop writepages mutexlock. So I'm afread the result is that it will mislead
> scheduling of block layer.
> 
> > WRITE. And, I thought new WRITE can be piggybacked into previous WRITE_SYNC.
> > 
> > IMO, this happens very occassionally since previous pending bio should be
> > WRITE_SYNC while a new request is WRITE. Even if this happens, the piggybacked
> > size would not exceed over bio's max pages.
> > If lots of WRITE come, we won't change at all.
> 
> I thinks this is related to writeback / blocklayer / cgroup subsystem which use
> this tag frequently, maybe we should Cc their's mailing list for more opinion...

Except cgroup, since we do not support it yet. :P

Anyway, I think we'd better verify the effect of this for a while.
For example, I'm able to write a simple program to measure fsync latency while
a bunch of buffered writes.
Meanwhile, I'll put it back to the end of dev-test repo. :)

Thanks,

> 
> What's your opinion? :)
> 
> thanks,
> 
> > 
> > Thanks,
> > 
> >>
> >> Thanks,
> >>
> >>>
> >>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> >>> ---
> >>>  fs/f2fs/data.c | 5 +++++
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> >>> index 7c8e219..c7c2022 100644
> >>> --- a/fs/f2fs/data.c
> >>> +++ b/fs/f2fs/data.c
> >>> @@ -267,6 +267,11 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
> >>>  
> >>>  	down_write(&io->io_rwsem);
> >>>  
> >>> +	/* WRITE can be merged into previous WRITE_SYNC */
> >>> +	if (io->bio && io->last_block_in_bio == fio->new_blkaddr - 1 &&
> >>> +			io->fio.op == fio->op && io->fio.op_flags == WRITE_SYNC)
> >>> +		fio->op_flags = WRITE_SYNC;
> >>> +
> >>>  	if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
> >>>  	    (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
> >>>  		__submit_merged_bio(io);
> >>>
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> > 

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [f2fs-dev] [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC
  2016-09-08  0:26       ` Jaegeuk Kim
@ 2016-09-08 16:09         ` Chao Yu
  0 siblings, 0 replies; 6+ messages in thread
From: Chao Yu @ 2016-09-08 16:09 UTC (permalink / raw)
  To: Jaegeuk Kim; +Cc: Chao Yu, linux-fsdevel, linux-kernel, linux-f2fs-devel

On 2016/9/8 8:26, Jaegeuk Kim wrote:
> On Wed, Sep 07, 2016 at 10:12:17PM +0800, Chao Yu wrote:
>> On 2016/9/3 2:36, Jaegeuk Kim wrote:
>>> On Fri, Sep 02, 2016 at 03:33:33PM +0800, Chao Yu wrote:
>>>> Hi Jaegeuk,
>>>>
>>>> On 2016/8/27 8:53, Jaegeuk Kim wrote:
>>>>> This can avoid bio splits due to different op_flags.
>>>>
>>>> I thought about this, but I think this is not a good idea to increase merging
>>>> ratio of pages in bio. It breaks the rule of SYNC/ASYNC IO defined by system
>>>> which indicate degree of IO emergency, finally, some/more non-emergent IO will
>>>> treated as emergent one by IO scheduler, it will interrupt SYNC IOs in block
>>>> layer, more seriously, it may make real SYNC IO starvation.
>>>
>>> I understand your concern.
>>> Originally, I tried to avoid breaking a big WRITE_SYNC by a small number of
>>
>> Hmm.. I'm worry about the opposite case: user triggers small WRITE_SYNC IO
>> periodically, meanwhile there are big number of WRITE, with our new approach,
>> actually we will increase the number of synchronous WRITE IO obviously because
>> we will mix ASYNC/SYNC WRITE into bio cache intensively more than before since
>> we drop writepages mutexlock. So I'm afread the result is that it will mislead
>> scheduling of block layer.
>>
>>> WRITE. And, I thought new WRITE can be piggybacked into previous WRITE_SYNC.
>>>
>>> IMO, this happens very occassionally since previous pending bio should be
>>> WRITE_SYNC while a new request is WRITE. Even if this happens, the piggybacked
>>> size would not exceed over bio's max pages.
>>> If lots of WRITE come, we won't change at all.
>>
>> I thinks this is related to writeback / blocklayer / cgroup subsystem which use
>> this tag frequently, maybe we should Cc their's mailing list for more opinion...
> 
> Except cgroup, since we do not support it yet. :P

Yeap.

> 
> Anyway, I think we'd better verify the effect of this for a while.
> For example, I'm able to write a simple program to measure fsync latency while
> a bunch of buffered writes.
> Meanwhile, I'll put it back to the end of dev-test repo. :)

Sounds good plan. Hoping we will not suffer from regression here. ;)

Thanks,

> 
> Thanks,
> 
>>
>> What's your opinion? :)
>>
>> thanks,
>>
>>>
>>> Thanks,
>>>
>>>>
>>>> Thanks,
>>>>
>>>>>
>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>> ---
>>>>>  fs/f2fs/data.c | 5 +++++
>>>>>  1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>>>> index 7c8e219..c7c2022 100644
>>>>> --- a/fs/f2fs/data.c
>>>>> +++ b/fs/f2fs/data.c
>>>>> @@ -267,6 +267,11 @@ void f2fs_submit_page_mbio(struct f2fs_io_info *fio)
>>>>>  
>>>>>  	down_write(&io->io_rwsem);
>>>>>  
>>>>> +	/* WRITE can be merged into previous WRITE_SYNC */
>>>>> +	if (io->bio && io->last_block_in_bio == fio->new_blkaddr - 1 &&
>>>>> +			io->fio.op == fio->op && io->fio.op_flags == WRITE_SYNC)
>>>>> +		fio->op_flags = WRITE_SYNC;
>>>>> +
>>>>>  	if (io->bio && (io->last_block_in_bio != fio->new_blkaddr - 1 ||
>>>>>  	    (io->fio.op != fio->op || io->fio.op_flags != fio->op_flags)))
>>>>>  		__submit_merged_bio(io);
>>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Linux-f2fs-devel mailing list
>>> Linux-f2fs-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>>

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-09-08 16:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-27  0:53 [PATCH] f2fs: merge WRITE bio into previous WRITE_SYNC Jaegeuk Kim
2016-09-02  7:33 ` Chao Yu
2016-09-02 18:36   ` Jaegeuk Kim
2016-09-07 14:12     ` [f2fs-dev] " Chao Yu
2016-09-08  0:26       ` Jaegeuk Kim
2016-09-08 16:09         ` Chao Yu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).