mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Yu <yuchao0@huawei.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Hyunchul Lee <hyc.lee@gmail.com>,
	<linux-f2fs-devel@lists.sourceforge.net>,
	<linux-kernel@vger.kernel.org>, <kernel-team@lge.com>,
	Hyunchul Lee <cheol.lee@lge.com>
Subject: Re: [RFC PATCH 0/2] apply write hints to select the type of segments
Date: Fri, 10 Nov 2017 10:31:14 +0800	[thread overview]
Message-ID: <d305845e-d971-553b-ad95-afc321c131b6@huawei.com> (raw)
In-Reply-To: <20171109181624.GA59398@jaegeuk-macbookpro.roam.corp.google.com>

On 2017/11/10 2:16, Jaegeuk Kim wrote:
> On 11/09, Chao Yu wrote:
>> On 2017/11/9 13:51, Hyunchul Lee wrote:
>>> From: Hyunchul Lee <cheol.lee@lge.com>
>>>
>>> Using write hints[1], applications can inform the life time of the data
>>> written to devices. and this[2] reported that the write hints patch
>>> decreased writes in NAND by 25%.
>>>
>>> This hints help F2FS to determine the followings.
>>>   1) the segment types where the data will be written.
>>>   2) the hints that will be passed down to devices with the data of segments.
>>>
>>> This patch set implements the first mapping from write hints to segment types
>>> as shown below.
>>>
>>>   hints                     segment type
>>>   -----                     ------------
>>>   WRITE_LIFE_SHORT          CURSEG_COLD_DATA
>>>   WRITE_LIFE_EXTREME        CURSEG_HOT_DATA
>>>   others                    CURSEG_WARM_DATA
>>>
>>> The F2FS poliy for hot/cold seperation has precedence over this hints, And
>>> hints are not applied in in-place update.
>>
>> Could we change to disable IPU if file/inode write hint is existing?
> 
> Well, this is a hint which is not related to IPU. I think user should be aware
> of controlling IPU.

Yes, no matter filesystem trigger IPU or OPU, in FTL, old PPA will always become
invalid (life is end), FTL only cares about how long PPA will become invalid
instead of how LPA/PPA mapps. So from FTL aspect, it's no problem. :)

But from f2fs space management aspect, IPU method can make effect of hot/cold
separating strategy becoming worse, e.g. if we trigger IPU for some hot datas,
data migration in hot segment can be postponed, result in high usage of hot
segment, leaving more work to GC.

So there is a trade-off in between reducing node writes in fsync and reduce GC
work with better hot/cold separating...

Thanks,

> 
>>>
>>> Before the second mapping is implemented, write hints are not passed down
>>> to devices. Because it is better that the data of a segment have the same 
>>> hint.
>>>
>>> [1]: c75b1d9421f80f4143e389d2d50ddfc8a28c8c35
>>> [2]: https://lwn.net/Articles/726477/
>>
>> Could you write a patch to support passing write hint to block layer for
>> buffered writes as below commit:
>> 0127251c45ae ("ext4: add support for passing in write hints for buffered writes")
>>
>> Thanks,
>>
>>>
>>> Hyunchul Lee (2):
>>>   f2fs: apply write hints to select the type of segments for buffered
>>>     write
>>>   f2fs: apply write hints to select the type of segment for direct write
>>>
>>>  fs/f2fs/data.c    | 101 ++++++++++++++++++++++++++++++++----------------------
>>>  fs/f2fs/f2fs.h    |   1 +
>>>  fs/f2fs/segment.c |  14 +++++++-
>>>  3 files changed, 74 insertions(+), 42 deletions(-)
>>>
> 
> .
> 

  reply	other threads:[~2017-11-10  2:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09  5:51 Hyunchul Lee
2017-11-09  5:51 ` [RFC PATHC 1/2] f2fs: apply write hints to select the type of segments for buffered write Hyunchul Lee
2017-11-09  8:21   ` Chao Yu
2017-11-09 18:19     ` Jaegeuk Kim
2017-11-09  5:51 ` [RFC PATHC 2/2] f2fs: apply write hints to select the type of segment for direct write Hyunchul Lee
2017-11-11  0:38   ` [f2fs-dev] " Chao Yu
2017-11-13  0:07     ` Hyunchul Lee
2017-11-13  1:24       ` Chao Yu
2017-11-13  1:48         ` Hyunchul Lee
2017-11-09  9:12 ` [RFC PATCH 0/2] apply write hints to select the type of segments Chao Yu
2017-11-09 18:16   ` Jaegeuk Kim
2017-11-10  2:31     ` Chao Yu [this message]
2017-11-10  0:23   ` Hyunchul Lee
2017-11-10  6:42     ` Chao Yu
2017-11-13  0:24       ` Hyunchul Lee
2017-11-13  1:26         ` Chao Yu
2017-11-13  1:35           ` Hyunchul Lee
2017-11-13  1:59             ` Chao Yu
2017-11-13  2:25               ` Hyunchul Lee
2017-11-14  4:20                 ` Jaegeuk Kim
2017-11-14  6:22                   ` Chao Yu
2017-11-15 16:27                     ` Jaegeuk Kim
2017-11-16  0:56                       ` Hyunchul Lee
2017-11-16  2:52                         ` Chao Yu
2017-11-16  3:58                           ` Jaegeuk Kim
2017-11-16  4:35                             ` Hyunchul Lee
2017-11-17 18:53                               ` Jaegeuk Kim
2017-11-20  2:12                                 ` Hyunchul Lee
2017-11-17 17:23 ` Christoph Hellwig
2017-11-17 18:36   ` Jaegeuk Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d305845e-d971-553b-ad95-afc321c131b6@huawei.com \
    --to=yuchao0@huawei.com \
    --cc=cheol.lee@lge.com \
    --cc=hyc.lee@gmail.com \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@lge.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®