On Mon, Oct 21, 2024 at 11:01:10AM +0530, Anuj Gupta wrote:
> > What is the meta_type for? To distintinguish PI from non-PI metadata?
>
> meta_type field is kept so that meta_types beyond integrity can also
> be supported in future. Pavel suggested this to Kanchan when this was
> discussed in LSF/MM.
>
> > Why doesn't this support non-PI metadata?
>
> It supports that. We have tested that (pi_type = 0 case).
What other metadata except for PI and plain non-integrity data
do you plan to support? This seems like a weird field. In doubt
just leave reserved space that is checked for 0 instead of adding
an encondig that doesn't make much sense. If we actually do end
up with a metadata scheme we can't encode into the pi_type we can
still use that reserved space.
>
> > Also PI or TO_PI might be
> > a better name than the rather generic integrity. (but I'll defer to
> > Martin if he has any good arguments for naming here).
>
> Open to a different/better name.
metadata?
> > > + /* Exclude meta IO as we don't support partial completion for that */
> > > return req->flags & REQ_F_ISREG ||
> > > - S_ISBLK(file_inode(req->file)->i_mode);
> > > + S_ISBLK(file_inode(req->file)->i_mode) ||
> > > + !(rw->kiocb.ki_flags & IOCB_HAS_METADATA);
> > > }
> >
> > What partial ocmpletions aren't supported? Note that this would
> > trigger easily as right now metadata is only added for block devices
> > anyway.
>
> It seems that this scenario is less likely to happen. The plumbing
> seemed a bit non trivial. I have the plan to look at it, once the
> initial version of this series goes in.
I still don't understand what this is trying to do, especially as
it is dead code with the checks above.
> >
> > > + if (unlikely(kiocb->ki_flags & IOCB_HAS_METADATA)) {
> >
> > For a workload using metadata this is everything but unlikely. Is
> > there a specific reason you're trying to override the existing
> > branch predictor here (although on at least x86_64 gcc these kinds
> > of unlikely calls tend to be no-ops anyway).
>
> The branch predictions were added to make it a bit friendly for
> non-metadata read/write case.
Throwing in these hints unless you have numbers justifying them is not
a good idea.
