On 5/3/18 2:58 PM, Adam Manzanares wrote: > > > On 5/3/18 1:24 PM, Jens Axboe wrote: >> On 5/3/18 2:15 PM, Adam Manzanares wrote: >>> >>> >>> On 5/3/18 11:33 AM, Matthew Wilcox wrote: >>>> On Thu, May 03, 2018 at 11:21:14AM -0700, adam.manzanares@xxxxxxx wrote: >>>>> If we want to avoid bloating struct kiocb, I suggest we turn the private field >>>>> into a union of the private and ki_ioprio field. It seems like the users of >>>>> the private field all use it at a point where we can yank the priority from >>>>> the kiocb before the private field is used. Comments and suggestions welcome. >>>> >>>> Or we could just make ki_hint a u8 or u16 ... seems unlikely we'll need >>>> 32 bits of ki_hint. (currently defined values are 1-5) >>> >>> I like the approach of using a u16 for the ki_hint. I'll update and >>> resubmit. >> >> It's intended to be a mask. If you do shrink it for now, then we need some >> guard code to ensure it can always carry what it needs to. >> > > Got it, I'll add the guard to rw_hint_valid along with a comment about > being limited by the size of ki_hint in case we get to a situation where > 16 bits is not enough. Other way around - the API should not be limited by the fact that some smaller type was chosen for an internal structure. Hence the guard/check should not be in rw_hint_valid, but rather around where you assign ki_hint. If/when we do extend the read/write hints, then we'll potentially need to bump ki_hint to accommodate it. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
