From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EA4EC43460 for ; Fri, 7 May 2021 08:59:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2632E6145E for ; Fri, 7 May 2021 08:59:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236527AbhEGJAm (ORCPT ); Fri, 7 May 2021 05:00:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235599AbhEGJAl (ORCPT ); Fri, 7 May 2021 05:00:41 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C89FC061574 for ; Fri, 7 May 2021 01:59:42 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id b19-20020a05600c06d3b029014258a636e8so4442893wmn.2 for ; Fri, 07 May 2021 01:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/nh1bbQT5CiK8IqERbTeRh4gKwm6+O6Vg+VARq82rio=; b=ddP9vw2/xz6l5rgNknMnioGUpBwslhkhK/Vqn+Kl45rxtCUI1B37VPu4ncHEAzfh5G lraIDVUeYC1DCwyViD6+lq/nLpHJ7NVA4UnG4dIh03OPLcXFQHOCKIsy6MTCyG7IvMTN ggSkExoADblSOWRHwZ8hPSr4yuGq19xGJhDe8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=/nh1bbQT5CiK8IqERbTeRh4gKwm6+O6Vg+VARq82rio=; b=qq+Fsy80Q1+EVYH20QYRA6uTlrTOu999DEiB4EFQZRDNiPtjHdAG2URsrmqIcGBtrL K7FeD0Hx6sQQvnXQna/U3WOh63EFGeQWGkGVzU6tI85oNP1L+1LWMClHZ0ibMA67G28L o22RISczkUupMJFQMqJF4gpffIgeImRSjxH17J7ovGmDQFzzw+yAs0dah82LRVVFXaW/ jvl6GUWaNDMh5Q9e/iMKznnsKHM0C+xtmLe0Ia+m6qB9VD8FYC51puO3fvqmlGHo1KXm AKsL4iPXyEd1qHsWHPgr9MGQv2EJVZLc4H/P/AcI8vEZTztc7El92cUnshKa8HjYjXw7 nIsw== X-Gm-Message-State: AOAM530jyKbWj8Dn3Me35viO+SCgmucz3wJZLXJYJCQpcorianwfkWYK hCuEEs+nHuCMJAlOdpcal0pf+A6PXjeFzA== X-Google-Smtp-Source: ABdhPJzduMczy9ysbmAMuqtbBG09rD7O4KiM9HF0LInaj4JHW6d0b9TrE4pquQXjf9xl813S56OsKA== X-Received: by 2002:a1c:7516:: with SMTP id o22mr19619041wmc.91.1620377980995; Fri, 07 May 2021 01:59:40 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id q10sm7138710wre.92.2021.05.07.01.59.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 May 2021 01:59:40 -0700 (PDT) Date: Fri, 7 May 2021 10:59:38 +0200 From: Daniel Vetter To: Kenny Ho Cc: Daniel Vetter , Alexei Starovoitov , Dave Airlie , Kenny Ho , Alexander Viro , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , bpf , Network Development , Linux-Fsdevel , "open list:CONTROL GROUP (CGROUP)" , Alex Deucher , amd-gfx list , DRI Development , Brian Welty Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL Message-ID: References: <20201103210418.q7hddyl7rvdplike@ast-mbp.dhcp.thefacebook.com> <20201103232805.6uq4zg3gdvw2iiki@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.10.32scarlett+ Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, May 06, 2021 at 10:06:32PM -0400, Kenny Ho wrote: > Sorry for the late reply (I have been working on other stuff.) > > On Fri, Feb 5, 2021 at 8:49 AM Daniel Vetter wrote: > > > > So I agree that on one side CU mask can be used for low-level quality > > of service guarantees (like the CLOS cache stuff on intel cpus as an > > example), and that's going to be rather hw specific no matter what. > > > > But my understanding of AMD's plans here is that CU mask is the only > > thing you'll have to partition gpu usage in a multi-tenant environment > > - whether that's cloud or also whether that's containing apps to make > > sure the compositor can still draw the desktop (except for fullscreen > > ofc) doesn't really matter I think. > This is not correct. Even in the original cgroup proposal, it > supports both mask and count as a way to define unit(s) of sub-device. > For AMD, we already have SRIOV that supports GPU partitioning in a > time-sliced-of-a-whole-GPU fashion. Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu cgroups controler to get started, since it's much closer to other cgroups that control bandwidth of some kind. Whether it's i/o bandwidth or compute bandwidht is kinda a wash. CU mask feels a lot more like an isolation/guaranteed forward progress kind of thing, and I suspect that's always going to be a lot more gpu hw specific than anything we can reasonably put into a general cgroups controller. Also for the time slice cgroups thing, can you pls give me pointers to these old patches that had it, and how it's done? I very obviously missed that part. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch