netdev - Re: [RFC] Add BPF_PROG_TYPE_CGROUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADnq5_Mwd-xHZQ4pt34=FPk2Gq3ij1FNHWsEz1LdS7_Dyo00iQ@mail.gmail.com>
Date:   Fri, 7 May 2021 15:55:39 -0400
From:   Alex Deucher <alexdeucher@...il.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Daniel Vetter <daniel@...ll.ch>, Kenny Ho <y2kenny@...il.com>,
        Song Liu <songliubraving@...com>,
        Andrii Nakryiko <andriin@...com>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kenny Ho <Kenny.Ho@....com>,
        "open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
        Brian Welty <brian.welty@...el.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        Martin KaFai Lau <kafai@...com>,
        Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Network Development <netdev@...r.kernel.org>,
        KP Singh <kpsingh@...omium.org>, Yonghong Song <yhs@...com>,
        bpf <bpf@...r.kernel.org>, Dave Airlie <airlied@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alex Deucher <alexander.deucher@....com>
Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL

On Fri, May 7, 2021 at 3:33 PM Tejun Heo <tj@...nel.org> wrote:
>
> Hello,
>
> On Fri, May 07, 2021 at 06:54:13PM +0200, Daniel Vetter wrote:
> > All I meant is that for the container/cgroups world starting out with
> > time-sharing feels like the best fit, least because your SRIOV designers
> > also seem to think that's the best first cut for cloud-y computing.
> > Whether it's virtualized or containerized is a distinction that's getting
> > ever more blurry, with virtualization become a lot more dynamic and
> > container runtimes als possibly using hw virtualization underneath.
>
> FWIW, I'm completely on the same boat. There are two fundamental issues with
> hardware-mask based control - control granularity and work conservation.
> Combined, they make it a significantly more difficult interface to use which
> requires hardware-specific tuning rather than simply being able to say "I
> wanna prioritize this job twice over that one".
>
> My knoweldge of gpus is really limited but my understanding is also that the
> gpu cores and threads aren't as homogeneous as the CPU counterparts across
> the vendors, product generations and possibly even within a single chip,
> which makes the problem even worse.
>
> Given that GPUs are time-shareable to begin with, the most universal
> solution seems pretty clear.

The problem is temporal partitioning on GPUs is much harder to enforce
unless you have a special case like SR-IOV.  Spatial partitioning, on
AMD GPUs at least, is widely available and easily enforced.  What is
the point of implementing temporal style cgroups if no one can enforce
it effectively?

Alex

>
> Thanks.
>
> --
> tejun