Hi Vivek, On Sun, Oct 4, 2009 at 2:11 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Sun, Oct 04, 2009 at 11:15:24AM +0200, Corrado Zoccolo wrote: >> Hi Vivek, >> My guess is that the formula that is used to handle this case is not >> very stable. > > In general I agree that formula to calculate the slice offset is very > puzzling as busy_queues varies and that changes the position of the task > sometimes. > > I am not sure what's the intent here by removing busy_queues stuff. I have > got two questions though. In the ideal case steady state, busy_queues will be a constant. Since we are just comparing the values between themselves, we can just remove this constant completely. Whenever it is not constant, it seems to me that it can cause wrong behaviour, i.e. when the number of processes with ready I/O reduces, a later coming request can jump before older requests. So it seems it does more harm than good, hence I suggest to remove it. Moreover, I suggest removing also the slice_resid part, since its semantics doesn't seem consistent. When computed, it is not the residency, but the remaining time slice. Then it is used to postpone, instead of anticipate, the position of the queue in the RR, that seems counterintuitive (it would be intuitive, though, if it was actually a residency, not a remaining slice, i.e. you already got your full share, so you can wait longer to be serviced again). > > - Why don't we keep it simple round robin where a task is simply placed at > the end of service tree. This should work for the idling case, since we provide service differentiation by means of time slice. For non-idling case, though, the appropriate placement of queues in the tree (as given by my formula) can still provide it. > > - Secondly, CFQ provides full slice length to queues only which are > idling (in case of sequenatial reader). If we do not enable idling, as > in case of NCQ enabled SSDs, then CFQ will expire the queue almost > immediately and put the queue at the end of service tree (almost). > > So if we don't enable idling, at max we can provide fairness, we > esseitially just let every queue dispatch one request and put at the end > of the end of service tree. Hence no fairness.... We should distinguish the two terms fairness and service differentiation. Fairness is when every queue gets the same amount of service share. This is not what we want when priorities are different (we want the service differentiation, instead), but is what we get if we do just round robin without idling. To fix this, we can alter the placement in the tree, so that if we have Q1 with slice S1, and Q2 with slice S2, always ready to perform I/O, we get that Q1 is in front of the three with probability S1/(S1+S2), and Q2 is in front with probability S2/(S1+S2). This is what my formula should achieve. Thanks, Corrado > > Thanks > Vivek > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
