On 4-1-2017 11:30, Johannes Berg wrote: >> However, we need to prefer something >>> - >>> always preferring the new sched scan could lead to bounces, so we >>> can >>> prefer (1) existing, (2) legacy-single type or (3) new-multi type, >>> but >>> not (4) new sched scan. >> >> Not sure I can follow. What is the difference between (1) and (2). > > (1) would never cancel any existing sched scan, regardless of type > (legacy vs. multi-capable) > > (2) would cancel an existing sched scan (in favour of a new one) if the > existing one is multi-capable > > (3) would cancel an existing sched scan (in favour of a new one) if the > existing one is legacy type yes, yes. sinking in :-p >> Also >> what do you consider (4) new sched scan. You mean the additional >> parameterization of the scheduled scan? > > No, I just meant any new request. Yeah, so there is already an existing/active sched scan. Clear. >>> I think preferring the existing would probably be best, i.e. refuse >>> legacy if any sched scan is running, and refuse multi if legacy is >>> running? >> >> Whatever the response above, I can understand this and it seems most >> straightforward. So I tend agree this is our best option although >> maybe for the wrong reason. > > :) Thanks for clarifying it. Gr. AvS
