All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyunchul Lee <hyc.lee@gmail.com>
To: Chao Yu <yuchao0@huawei.com>
Cc: kernel-team@lge.com, Jaegeuk Kim <jaegeuk@kernel.org>,
	Hyunchul Lee <cheol.lee@lge.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [RFC PATCH 0/2] apply write hints to select the type of segments
Date: Mon, 13 Nov 2017 10:35:06 +0900	[thread overview]
Message-ID: <5A08F6CA.6040507@gmail.com> (raw)
In-Reply-To: <c3199798-cd5b-afca-845b-73817c77c902@huawei.com>

On 11/13/2017 10:26 AM, Chao Yu wrote:
> On 2017/11/13 8:24, Hyunchul Lee wrote:
>> On 11/10/2017 03:42 PM, Chao Yu wrote:
>>> On 2017/11/10 8:23, Hyunchul Lee wrote:
>>>> Hello, Chao
>>>>
>>>> On 11/09/2017 06:12 PM, 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?
>>>>>
>>>>
>>>> I am afraid that this makes side effects. for example, this could cause
>>>> out-of-place updates even when there are not enough free segments. 
>>>> I can write the patch that handles these situations. But I wonder 
>>>> that this is required, and I am not sure which IPU polices can be disabled.
>>>
>>> Oh, As I replied in another thread, I think IPU just affects filesystem
>>> hot/cold separating, rather than this feature. So I think it will be okay
>>> to not consider it.
>>>
>>>>
>>>>>>
>>>>>> 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")
>>>>>
>>>>
>>>> Sure I will. I wrote it already ;)
>>>
>>> Cool, ;)
>>>
>>>> I think that datas from the same segment should be passed down with the same
>>>> hint, and the following mapping is reasonable. I wonder what is your opinion
>>>> about it.
>>>>
>>>>   segment type               hints
>>>>   ------------               -----
>>>>   CURSEG_COLD_DATA           WRITE_LIFE_EXTREME
>>>>   CURSEG_HOT_DATA            WRITE_LIFE_SHORT
>>>>   CURSEG_COLD_NODE           WRITE_LIFE_NORMAL
>>>
>>> We have WRITE_LIFE_LONG defined rather than WRITE_LIFE_NORMAL in fs.h?
>>>
>>>>   CURSEG_HOT_NODE            WRITE_LIFE_MEDIUM
>>>
>>> As I know, in scenario of cell phone, data of meta_inode is hottest, then hot
>>> data, warm node, and cold node should be coldest. So I suggested we can define
>>> as below:
>>>
>>> META_DATA			WRITE_LIFE_SHORT
>>> HOT_DATA & WARM_NODE		WRITE_LIFE_MEDIUM
>>> HOT_NODE & WARM_DATA		WRITE_LIFE_LONG
>>> COLD_NODE & COLD_DATA		WRITE_LIFE_EXTREME
>>>
>>
>> I agree, But I am not sure that assigning the same hint to a node and data
>> segment is good. Because NVMe is likely to write them in the same erase 
>> block if they have the same hint.
> 
> If we do not give the hint, they can still be written to the same erase block,
> right? it will not be worse?
> 

If the hint is not given, I think that they could be written to 
the same erase block, or not. But if we give the same hint, they are written
to the same block.
I am not sure ;)

> Thanks,
> 
>>
>> Thanks.
>>
>>> Thanks,
>>>
>>>>   others                     WRITE_LIFE_NONE
>>>>  
>>>>> 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(-)
>>>>>>
>>>>>
>>>>>
>>>>
>>>> Thanks
>>>>
>>>> .
>>>>
>>>
>>>
>>
>> .
>>
> 
> 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

WARNING: multiple messages have this Message-ID (diff)
From: Hyunchul Lee <hyc.lee@gmail.com>
To: Chao Yu <yuchao0@huawei.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	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: Mon, 13 Nov 2017 10:35:06 +0900	[thread overview]
Message-ID: <5A08F6CA.6040507@gmail.com> (raw)
In-Reply-To: <c3199798-cd5b-afca-845b-73817c77c902@huawei.com>

On 11/13/2017 10:26 AM, Chao Yu wrote:
> On 2017/11/13 8:24, Hyunchul Lee wrote:
>> On 11/10/2017 03:42 PM, Chao Yu wrote:
>>> On 2017/11/10 8:23, Hyunchul Lee wrote:
>>>> Hello, Chao
>>>>
>>>> On 11/09/2017 06:12 PM, 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?
>>>>>
>>>>
>>>> I am afraid that this makes side effects. for example, this could cause
>>>> out-of-place updates even when there are not enough free segments. 
>>>> I can write the patch that handles these situations. But I wonder 
>>>> that this is required, and I am not sure which IPU polices can be disabled.
>>>
>>> Oh, As I replied in another thread, I think IPU just affects filesystem
>>> hot/cold separating, rather than this feature. So I think it will be okay
>>> to not consider it.
>>>
>>>>
>>>>>>
>>>>>> 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")
>>>>>
>>>>
>>>> Sure I will. I wrote it already ;)
>>>
>>> Cool, ;)
>>>
>>>> I think that datas from the same segment should be passed down with the same
>>>> hint, and the following mapping is reasonable. I wonder what is your opinion
>>>> about it.
>>>>
>>>>   segment type               hints
>>>>   ------------               -----
>>>>   CURSEG_COLD_DATA           WRITE_LIFE_EXTREME
>>>>   CURSEG_HOT_DATA            WRITE_LIFE_SHORT
>>>>   CURSEG_COLD_NODE           WRITE_LIFE_NORMAL
>>>
>>> We have WRITE_LIFE_LONG defined rather than WRITE_LIFE_NORMAL in fs.h?
>>>
>>>>   CURSEG_HOT_NODE            WRITE_LIFE_MEDIUM
>>>
>>> As I know, in scenario of cell phone, data of meta_inode is hottest, then hot
>>> data, warm node, and cold node should be coldest. So I suggested we can define
>>> as below:
>>>
>>> META_DATA			WRITE_LIFE_SHORT
>>> HOT_DATA & WARM_NODE		WRITE_LIFE_MEDIUM
>>> HOT_NODE & WARM_DATA		WRITE_LIFE_LONG
>>> COLD_NODE & COLD_DATA		WRITE_LIFE_EXTREME
>>>
>>
>> I agree, But I am not sure that assigning the same hint to a node and data
>> segment is good. Because NVMe is likely to write them in the same erase 
>> block if they have the same hint.
> 
> If we do not give the hint, they can still be written to the same erase block,
> right? it will not be worse?
> 

If the hint is not given, I think that they could be written to 
the same erase block, or not. But if we give the same hint, they are written
to the same block.
I am not sure ;)

> Thanks,
> 
>>
>> Thanks.
>>
>>> Thanks,
>>>
>>>>   others                     WRITE_LIFE_NONE
>>>>  
>>>>> 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(-)
>>>>>>
>>>>>
>>>>>
>>>>
>>>> Thanks
>>>>
>>>> .
>>>>
>>>
>>>
>>
>> .
>>
> 
> 

  reply	other threads:[~2017-11-13  1:35 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09  5:51 [RFC PATCH 0/2] apply write hints to select the type of segments 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  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  0:07       ` Hyunchul Lee
2017-11-13  1:24       ` Chao Yu
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  9:12   ` Chao Yu
2017-11-09 18:16   ` Jaegeuk Kim
2017-11-09 18:16     ` Jaegeuk Kim
2017-11-10  2:31     ` Chao Yu
2017-11-10  2:31       ` Chao Yu
2017-11-10  0:23   ` Hyunchul Lee
2017-11-10  6:42     ` Chao Yu
2017-11-10  6:42       ` Chao Yu
2017-11-13  0:24       ` Hyunchul Lee
2017-11-13  0:24         ` Hyunchul Lee
2017-11-13  1:26         ` Chao Yu
2017-11-13  1:26           ` Chao Yu
2017-11-13  1:35           ` Hyunchul Lee [this message]
2017-11-13  1:35             ` Hyunchul Lee
2017-11-13  1:59             ` Chao Yu
2017-11-13  1:59               ` Chao Yu
2017-11-13  2:25               ` Hyunchul Lee
2017-11-14  4:20                 ` Jaegeuk Kim
2017-11-14  4:20                   ` Jaegeuk Kim
2017-11-14  6:22                   ` Chao Yu
2017-11-14  6:22                     ` Chao Yu
2017-11-15 16:27                     ` Jaegeuk Kim
2017-11-15 16:27                       ` Jaegeuk Kim
2017-11-16  0:56                       ` Hyunchul Lee
2017-11-16  0:56                         ` Hyunchul Lee
2017-11-16  2:52                         ` Chao Yu
2017-11-16  2:52                           ` Chao Yu
2017-11-16  3:58                           ` Jaegeuk Kim
2017-11-16  3:58                             ` Jaegeuk Kim
2017-11-16  4:35                             ` Hyunchul Lee
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 17:23   ` Christoph Hellwig
2017-11-17 18:36   ` Jaegeuk Kim
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=5A08F6CA.6040507@gmail.com \
    --to=hyc.lee@gmail.com \
    --cc=cheol.lee@lge.com \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@lge.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuchao0@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.