On 3/10/22 2:52 PM, Bean Huo (beanhuo) wrote: > Micron Confidential > >>>> >>>>> >>>>> You do both realize that this is just the file specific hint? Inode >>>>> based hints will still work fine for UFS. >>>>> >>>>> -- >>>>> Jens Axboe >>>> >>>> Jens, >>>> >>>> Thanks for this reply. >>>> >>>> This whole patch series removes support for per-bio write_hint. >>>> Without bio write_hint, F2FS won't be able to cascade Hot/Warm/Cold >>>> information to SCSI / UFS driver. >>>> >>>> This is my current understanding. I might be wrong but I don't think >>>> we Are concerned with inode hint (as well as file hints). >>> >>> But ufs/scsi doesn't use it in mainline, as far as I can tell. So how >>> does that work? >> >> Hi Luca, >> >> I'm not aware of any Android branch on which the UFS driver or the SCSI core >> uses bi_write_hint or the struct request write_hint member. Did I perhaps >> overlook something? >> >> Thanks, >> > > > Bart, > > Yes, in upstream linux and upstream android, there is no such code. > But as we know, mobile customers have used bio->bi_write_hint in their > products for years. And the group ID is set according to > bio->bi_write_hint before passing the CDB to UFS. > > > lrbp = &hba->lrb[tag]; > > WARN_ON(lrbp->cmd); > + if(cmd->cmnd[0] == WRITE_10) > +{ > + cmd->cmnd[6] = (0x1f& cmd->request->bio->bi_write_hint); > +} > lrbp->cmd = cmd; > lrbp->sense_bufflen = UFS_SENSE_SIZE; > lrbp->sense_buffer = cmd->sense_buffer; > > I don't know why they don't push these changes to the community, maybe > it's because changes across the file system and block layers are > unacceptable to the block layer and FS. but for sure we should now > warn them to push to the community as soon as possible. If the code isn't upstream, it's a bit late to start thinking about that now. This feature has existed for 5 years at this point, and the only consumer was NVMe. The upstream kernel cares only about what is in-tree, as that is the only part we can modify and fix. We change/modify internal kernel APIs all the time, which is how tech debt is removed and the long term sanity of the project is maintained. This in turn means that out-of-tree code will break, that's just a natural side effect and something we can't do anything about. If at some point there's a desire to actually try and upstream this support, then we'll be happy to review that patchset. Or you can continue to stay out-of-tree and just patch in what you need. If you're already modifying core code, then that shouldn't be a problem. -- Jens Axboe