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]
Date:   Fri, 7 May 2021 15:33:27 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Alex Deucher <alexdeucher@...il.com>, 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

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.

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ