linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>, Kenny Ho <y2kenny@gmail.com>,
	Song Liu <songliubraving@fb.com>,
	Andrii Nakryiko <andriin@fb.com>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kenny Ho <Kenny.Ho@amd.com>,
	"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,
	Brian Welty <brian.welty@intel.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Martin KaFai Lau <kafai@fb.com>,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Network Development <netdev@vger.kernel.org>,
	KP Singh <kpsingh@chromium.org>, Yonghong Song <yhs@fb.com>,
	bpf <bpf@vger.kernel.org>, Dave Airlie <airlied@gmail.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL
Date: Fri, 7 May 2021 16:59:13 -0400	[thread overview]
Message-ID: <YJWqIVnX9giaKMTG@slm.duckdns.org> (raw)
In-Reply-To: <CADnq5_Mwd-xHZQ4pt34=FPk2Gq3ij1FNHWsEz1LdS7_Dyo00iQ@mail.gmail.com>

Hello,

On Fri, May 07, 2021 at 03:55:39PM -0400, Alex Deucher wrote:
> 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?

So, if generic fine-grained partitioning can't be implemented, the right
thing to do is stopping pushing for full-blown cgroup interface for it. The
hardware simply isn't capable of being managed in a way which allows generic
fine-grained hierarchical scheduling and there's no point in bloating the
interface with half baked hardware dependent features.

This isn't to say that there's no way to support them, but what have been
being proposed is way too generic and ambitious in terms of interface while
being poorly developed on the internal abstraction and mechanism front. If
the hardware can't do generic, either implement the barest minimum interface
(e.g. be a part of misc controller) or go driver-specific - the feature is
hardware specific anyway. I've repeated this multiple times in these
discussions now but it'd be really helpful to try to minimize the interace
while concentrating more on internal abstractions and actual control
mechanisms.

Thanks.

-- 
tejun

  reply	other threads:[~2021-05-07 20:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 15:23 [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL Kenny Ho
2020-11-02 19:23 ` Kenny Ho
2020-11-03  5:32   ` Alexei Starovoitov
2020-11-03  5:39     ` Kenny Ho
2020-11-03  5:42       ` Alexei Starovoitov
2020-11-03 19:19         ` Kenny Ho
2020-11-03 21:04           ` Alexei Starovoitov
2020-11-03 22:57             ` Kenny Ho
2020-11-03 23:28               ` Alexei Starovoitov
2021-02-01 14:49                 ` Daniel Vetter
2021-02-01 16:51                   ` Kenny Ho
2021-02-03 11:09                     ` Daniel Vetter
2021-02-03 19:01                       ` Kenny Ho
2021-02-05 13:49                         ` Daniel Vetter
2021-05-07  2:06                           ` Kenny Ho
2021-05-07  8:59                             ` Daniel Vetter
2021-05-07 15:33                               ` Kenny Ho
2021-05-07 16:13                                 ` Daniel Vetter
2021-05-07 16:19                                   ` Alex Deucher
2021-05-07 16:26                                     ` Daniel Vetter
2021-05-07 16:31                                       ` Alex Deucher
2021-05-07 16:50                                         ` Alex Deucher
2021-05-07 16:54                                           ` Daniel Vetter
2021-05-07 17:04                                             ` Kenny Ho
2021-05-07 19:33                                             ` Tejun Heo
2021-05-07 19:55                                               ` Alex Deucher
2021-05-07 20:59                                                 ` Tejun Heo [this message]
2021-05-07 22:30                                                   ` Alex Deucher
2021-05-07 23:45                                                     ` Tejun Heo
2021-05-11 15:48                                                       ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJWqIVnX9giaKMTG@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=Kenny.Ho@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brian.welty@intel.com \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=daniel@iogearbox.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=y2kenny@gmail.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).