lkml.org 
[lkml]   [2018]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping
    On 07-Aug 14:35, Juri Lelli wrote:
    > On 06/08/18 17:39, Patrick Bellasi wrote:
    >
    > [...]
    >
    > > @@ -4218,6 +4245,13 @@ static int __sched_setscheduler(struct task_struct *p,
    > > return retval;
    > > }
    > >
    > > + /* Configure utilization clamps for the task */
    > > + if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) {
    > > + retval = __setscheduler_uclamp(p, attr);
    > > + if (retval)
    > > + return retval;
    > > + }
    > > +
    >
    > IIUC, this is available to root and non-root users. In the latter case,
    > how do we cope with the fact that some user might occupy all the
    > available clamping groups configured for the system?

    That's a very good point, glad you noticed it.

    What concern me most is that we set constraints to the cgroups
    delegation model. If all clamp groups have been used it could be
    not possible for a parent group to shrink resources for its subgroups.

    In both cases however, in principle, I think we can live with the idea
    that the "System Management Software" (SMS) can pre-allocate all the
    required boost groups at boot time; malicious tasks and dependent
    groups will eventually get an -ENOSPC error.

    These are the main reason why I did not posted a more "safe" solution:
    this series is already big enough, a properly (pre)configured system
    is still reasonably functional safe and this feature can be added in
    a second step.

    However, I already have a couple of possible extensions/fixes which I
    can add on top on the next respin. They are along these lines:
    1) make CAP_SYS_NICE protected the clamp groups, with an optional boot
    time parameter to relax this check
    2) add discretization support to clamp groups allocation

    This second feature specifically, will ensure that clamp values are
    always mapped into one of the available clamp groups. While the exact
    clamp value can always be used for tasks placement biasing, when it
    comes to frequency selection biasing, depending on concurrently
    running tasks, you can end up with an effective clamp value which is a
    rounded up.

    Will likely add a couple of additional patches on v4 posting.
    Do you have any other possible idea?

    Cheers Patrick

    --
    #include <best/regards.h>

    Patrick Bellasi

    \
     
     \ /
      Last update: 2018-08-09 11:15    [W:4.278 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site