Re: [f2fs-dev] [PATCH 1/2] f2fs: pass down write hints to block layer for bufferd write
Brought to you by:
kjgkr
Menu
▾
▴
Re: [f2fs-dev] [PATCH 1/2] f2fs: pass down write hints to block layer for bufferd write
|
From: Jaegeuk K. <ja...@ke...> - 2017-12-28 16:32:28
|
On 12/28, Hyunchul Lee wrote: > Hi Jaegeuk, > > On 12/28/2017 12:26 PM, Jaegeuk Kim wrote: > > On 12/23, Chao Yu wrote: > >> On 2017/12/15 10:06, Jaegeuk Kim wrote: > >>> On 12/14, Hyunchul Lee wrote: > >>>> Hi Jaegeuk, > >>>> > >>>> I need your comment about the fs_iohint mount option. > >>>> > >>>> a) w/o fs_iohint, propagate user hints to low layer. > >>>> b) w/ fs_iohint, ignore user hints, and use hints which is generated > >>>> with F2FS. > >>>> > >>>> Chao suggests this option. because user hints are more accurate than > >>>> file system. > >>>> > >>>> This is resonable, But I have some concerns about this option. > >>>> The first thing is that blocks of a segments have different hints. This > >>>> could make GC less effective. > >>>> The second is that the separation between LIFE_MEDIUM and LIFE_LONG is > >>>> really needed. I think that difference between them is a little ambigous > >>>> for users, and LIFE_SHORT and LIFE_EXTREME is converted to different > >>>> hints by F2FS. > >>> > >>> I think what we really can do would assign many user hints to our 3 DATA > >>> logs likewise rw_hint_to_seg_type(), since it's just hints for user data. > >>> Then, we can decide how to keep that as much as possible, since we have > >>> another filesystem metadata such as meta and nodes. In addition, I don't > >>> think we have to keep the original user-hints which makes F2FS logs be > >>> messed up. > >>> > >>> With that mind, I can think of the below cases. Especially, if user wants > >>> to keep their io_hints, we'd better recommend to use direct_io w/o fs_iohints. > >> > >> > >> > >>> In order to keep this policy, I think fs_iohints would be better to be a > >>> feature set by mkfs.f2fs and detected by sysfs entries for users. > >>> > >>> 1) w/ fs_iohints > >>> > >>> User F2FS Block > >>> ------------------------------------------------------------------- > >>> Meta WRITE_LIFE_MEDIUM > >>> HOT_NODE WRITE_LIFE_NOTSET > >>> WARM_NODE -' > >>> COLD_NODE WRITE_LIFE_NONE > >>> ioctl(cold) COLD_DATA WRITE_LIFE_EXTREME > >>> extention list -' -' > >>> WRITE_LIFE_EXTREME -' -' > >>> WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT > >>> > >>> -- buffered_io > >>> WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_LONG > >>> WRITE_LIFE_NONE -' -' > >>> WRITE_LIFE_MEDIUM -' -' > >>> WRITE_LIFE_LONG -' -' > >>> > >>> -- direct_io (Not recommendable) > >>> WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET > >>> WRITE_LIFE_NONE -' WRITE_LIFE_NONE > >>> WRITE_LIFE_MEDIUM -' WRITE_LIFE_MEDIUM > >>> WRITE_LIFE_LONG -' WRITE_LIFE_LONG > >> > >> Agreed with above IO hint mapping rule. > >> > >>> > >>> 2) w/o fs_iohints > >>> > >>> User F2FS Block > >>> ------------------------------------------------------------------- > >>> Meta - > >>> HOT_NODE - > >>> WARM_NODE - > >>> COLD_NODE - > >>> ioctl(cold) COLD_DATA - > >>> extention list -' - > >>> > >>> -- buffered_io > >>> WRITE_LIFE_EXTREME COLD_DATA - > >>> WRITE_LIFE_SHORT HOT_DATA - > >>> WRITE_LIFE_NOT_SET WARM_DATA - > >>> WRITE_LIFE_NONE -' - > >>> WRITE_LIFE_MEDIUM -' - > >>> WRITE_LIFE_LONG -' - > >> > >> Now we recommend direct_io if user wants to give IO hint for storage, I suspect > >> that user would suffer performance regression issue w/o buffered IO. > >> > >> Another problem is that, now, in Android, it will be very hard to prompt > >> application to migrate their IO pattern from buffered IO to direct IO, one > >> possible way is distinguishing user data lifetime from FWK, e.g. set > >> WRITE_LIFE_SHORT for cache file or tmp file, set WRITE_LIFE_EXTREME for media file. > >> > >> In order to support buffered_io, would it be better to change mapping as below? > >> > >> -- buffered_io > >> WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME > >> WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT > >> WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET > >> WRITE_LIFE_NONE -' -' > >> WRITE_LIFE_MEDIUM -' -' > >> WRITE_LIFE_LONG -' -' > > > > Agreed, and it makes more sense that we'd better keep the write hints on > > userdata given by applications. > > > > BTW, since we couldn't get any performance numbers with these, how about > > adding a mount option like "-o iohints=MODE" where MODE may be one of > > "fs-based", "user-based", and "off"? > > > > "fs-based" equals "with fs_iohints", "user-based" equals "without fs_iohints" > + Chao's suggest, and "off" means not passing down hints to block layer. right? Yup, this'd allow us to add more options easily later. Thanks, > > Thanks. > > > Thanks, > > > >> > >> Thanks, > >> > >>> > >>> -- direct_io > >>> WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME > >>> WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT > >>> WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET > >>> WRITE_LIFE_NONE -' WRITE_LIFE_NONE > >>> WRITE_LIFE_MEDIUM -' WRITE_LIFE_MEDIUM > >>> WRITE_LIFE_LONG -' WRITE_LIFE_LONG > >>> > >>> > >>> Note that, I don't much care about how to manipulate streamid in nvme driver > >>> in terms of LIFE_NONE or LIFE_NOTSET, since other drivers can handle them > >>> in different ways. Taking a look at the definition, at least, we don't need > >>> to assume that those are same at all. For example, if we can expolit this in > >>> UFS driver, we can pass all the stream ids to the device as context ids. > >>> > >>> Thanks, > >>> > >>>> > >>>> Thanks. > >>>> > >>>> On 12/12/2017 11:45 AM, Chao Yu wrote: > >>>>> Hi Hyunchul, > >>>>> > >>>>> On 2017/12/12 10:15, Hyunchul Lee wrote: > >>>>>> Hi Chao, > >>>>>> > >>>>>> On 12/11/2017 10:15 PM, Chao Yu wrote: > >>>>>>> Hi Hyunchul, > >>>>>>> > >>>>>>> On 2017/12/1 16:28, Hyunchul Lee wrote: > >>>>>>>> Hi Chao, > >>>>>>>> > >>>>>>>> On 11/30/2017 04:06 PM, Chao Yu wrote: > >>>>>>>>> Hi Hyunchul, > >>>>>>>>> > >>>>>>>>> On 2017/11/28 8:23, Hyunchul Lee wrote: > >>>>>>>>>> From: Hyunchul Lee <che...@lg...> > >>>>>>>>>> > >>>>>>>>>> This implements which hint is passed down to block layer > >>>>>>>>>> for datas from the specific segment type. > >>>>>>>>>> > >>>>>>>>>> segment type hints > >>>>>>>>>> ------------ ----- > >>>>>>>>>> COLD_NODE & COLD_DATA WRITE_LIFE_EXTREME > >>>>>>>>>> WARM_DATA WRITE_LIFE_NONE > >>>>>>>>>> HOT_NODE & WARM_NODE WRITE_LIFE_LONG > >>>>>>>>>> HOT_DATA WRITE_LIFE_MEDIUM > >>>>>>>>>> META_DATA WRITE_LIFE_SHORT > >>>>>>>>> > >>>>>>>>> Just noticed, if our user do not give the hint via ioctl, f2fs can > >>>>>>>>> provider hint to lower layer according to hot/cold separation ability, > >>>>>>>>> it will be okay. But once user give his hint which may be more accurate > >>>>>>>>> than filesystem, hint converted by f2fs may be wrong. > >>>>>>>>> > >>>>>>>>> So what do you think of adding an option to control whether filesystem > >>>>>>>>> can convert hint user given? > >>>>>>>>> > >>>>>>>> > >>>>>>>> I think it is okay for LIFE_SHORT and LIFE_EXTREME. because they are > >>>>>>>> converted to different hints. > >>>>>>> > >>>>>>> What I mean is introducing a mount option, e.g. fs_iohint, > >>>>>>> a) w/o fs_iohint, propagate file/inode io_hint to low layer. > >>>>>>> b) w/ fs_iohint, ignore file/inode io_hint, use io_hint which is generated > >>>>>>> with filesystem's private rule. > >>>>>>> > >>>>>> > >>>>>> Okay, I will implement this option and send this patch again. > >>>>> > >>>>> Let's wait for Jaegeuk's comments first? > >>>>> > >>>>>> > >>>>>> Without fs_iohint, Even if data blocks are moved due to GC, > >>>>>> we should keep user hints. And if user hints are not given, > >>>>>> any hints are not passed down to block layer, right? > >>>>> > >>>>> Hmm.. that will be a problem, IMO, we can store last user's io_hint into inode > >>>>> layout, so later when we trigger GC, we can use the last io_hint in inode rather > >>>>> than giving no hint or fs' hint. > >>>>> > >>>>> I think it needs to discuss with original author of IO hint, what is the IO hint > >>>>> policy when filesystem move block by itself after inode has been released in system. > >>>>> > >>>>> Thanks, > >>>>> > >>>>>> > >>>>>> Thank you for comments. > >>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>>> > >>>>>>>> file hint segment type io hint > >>>>>>>> --------- ------------ ------- > >>>>>>>> LIFE_SHORT HOT_DATA LIFE_MEDIUM > >>>>>>>> LIFE_MEDIUM WARM_DATA LIFE_NONE > >>>>>>>> LIFE_LONG WARM_DATA LIFE_NONE > >>>>>>>> LIFE_EXTREME COLD_DATA LIFE_EXTREME > >>>>>>>> > >>>>>>>> the problem is that LIFE_MEDIUM and LIFE_LONG are converted to > >>>>>>>> the same hint, LIFE_NONE. I am not sure that the seperation between > >>>>>>>> LIFE_MEDIUM and LIFE_LONG is really needed. Because I guess that the > >>>>>>>> difference between them is a little ambigous for users, and if WARM_DATA > >>>>>>>> segment has two different hints, it can makes GC non-efficient. > >>>>>>>> > >>>>>>>> I wonder your thought about this. > >>>>>>>> > >>>>>>>> Thanks. > >>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> ------------------------------------------------------------------------------ > >>>>>>>> Check out the vibrant tech community on one of the world's most > >>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>>>>>>> _______________________________________________ > >>>>>>>> Linux-f2fs-devel mailing list > >>>>>>>> Lin...@li... > >>>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> . > >>>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------------ > >>>>> Check out the vibrant tech community on one of the world's most > >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>>>> _______________________________________________ > >>>>> Linux-f2fs-devel mailing list > >>>>> Lin...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > >>>>> > >>> > >>> . > >>> > > |
