On Tue, Dec 18, 2018 at 9:58 AM 'Suren Baghdasaryan' via kernel-team <kernel-t...@android.com> wrote: > > Current design supports only whole percentages and if userspace needs > more granularity then it has to use usecs. > I agree that usecs cover % usecase and "threshold * win / 100" is > simple enough for userspace to calculate. I'm fine with changing to > usecs only.
Suren, please avoid top-posting to LKML. Also I was going to say the same thing, just usecs only is better. thanks, - Joel > On Tue, Dec 18, 2018 at 9:30 AM Johannes Weiner <han...@cmpxchg.org> wrote: > > > > On Tue, Dec 18, 2018 at 11:46:22AM +0100, Peter Zijlstra wrote: > > > On Mon, Dec 17, 2018 at 05:21:05PM -0800, Suren Baghdasaryan wrote: > > > > On Mon, Dec 17, 2018 at 8:22 AM Peter Zijlstra <pet...@infradead.org> > > > > wrote: > > > > > > > > How well has this thing been fuzzed? Custom string parser, yay! > > > > > > > > Honestly, not much. Normal cases and some obvious corner cases. Will > > > > check if I can use some fuzzer to get more coverage or will write a > > > > script. > > > > I'm not thrilled about writing a custom parser, so if there is a > > > > better way to handle this please advise. > > > > > > The grammar seems fairly simple, something like: > > > > > > some-full = "some" | "full" ; > > > threshold-abs = integer ; > > > threshold-pct = integer, { "%" } ; > > > threshold = threshold-abs | threshold-pct ; > > > window = integer ; > > > trigger = some-full, space, threshold, space, window ; > > > > > > And that could even be expressed as two scanf formats: > > > > > > "%4s %u%% %u" , "%4s %u %u" > > > > > > which then gets your something like: > > > > > > char type[5]; > > > > > > if (sscanf(input, "%4s %u%% %u", &type, &pct, &window) == 3) { > > > // do pct thing > > > } else if (sscanf(intput, "%4s %u %u", &type, &thres, &window) == 3) { > > > // do abs thing > > > } else return -EFAIL; > > > > > > if (!strcmp(type, "some")) { > > > // some > > > } else if (!strcmp(type, "full")) { > > > // full > > > } else return -EFAIL; > > > > > > // do more > > > > We might want to drop the percentage notation. > > > > While it's somewhat convenient, it's also not unreasonable to ask > > userspace to do a simple "threshold * win / 100" themselves, and it > > would simplify the interface spec and the parser. > > > > Sure, psi outputs percentages, but only for fixed window sizes, so > > that actually saves us something, whereas this parser here needs to > > take a fractional anyway. The output is also in decimal notation, > > which is necessary for granularity. And I really don't think we want > > to add float parsing on top of this interface spec. > > > > So neither the convenience nor the symmetry argument are very > > compelling IMO. It might be better to just not go there. > > -- > You received this message because you are subscribed to the Google Groups > "kernel-team" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. >