Sorry for the delay. Overlooked this comment... On Tue, Jul 24, 2018 at 8:49 AM, Patrick Bellasi <patrick.bell...@arm.com> wrote:
> On 24-Jul 08:28, Suren Baghdasaryan wrote: > > Hi Patrick. Thanks for the explanation and links. No more questions > > from me on this one :) > > No problems at all! > > The important question is instead: does it makes sense for you too? > Well, it still feels unnatural to me due to the definition of the boost (at least this much CPU bandwidth but higher should be fine). Say I have a task which normally has specific boost and clamp requirements (say TG.UCLAMP_MIN=20, TG.UCLAMP_MAX=80) which I want to temporarily boost using a syscall to UCLAMP_MIN=60 (let's say a process should handle some request and temporarily needs more CPU bandwidth). With this interface we can clamp more than TG.UCLAMP_MAX value but we can't boost more than TG.UCLAMP_MIN. For this usecase I would have to set TG.UCLAMP_MIN=80, then use syscall to set SYSCALL.UCLAMP_MIN=20 to get effective UCLAMP_MIN=20 and then set SYSCALL.UCLAMP_MIN=60 when I need that temporary boost. To summarize, while this API does not stop me from achieving the desired result it requires some hoop-jumping :) > > I think the important bits are that we are all on the same page about > the end goals and features we like to have as well as the interface we use. > This last has to fits best our goals and features while still being > perfectly aligned with the frameworks we are integrating into... and > that's still under discussion with Tejun on PATCH 08/12. > > Thanks again for your review! > > Cheers Patrick > > -- > #include <best/regards.h> > > Patrick Bellasi >
