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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 CED82C433B4 for ; Fri, 7 May 2021 08:59:44 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5C4C3613C5 for ; Fri, 7 May 2021 08:59:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C4C3613C5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 62EB56EDF4; Fri, 7 May 2021 08:59:43 +0000 (UTC) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 526686EDF0 for ; Fri, 7 May 2021 08:59:42 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id b11-20020a7bc24b0000b0290148da0694ffso6711799wmj.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=ILTOKjGzi/GVAYr18y1b4MZnQBrI51jZU3pY/48LiSxsw/jevtVIZ4gToDOWcHdWR1 NcNk3yjFxhaqoyLIDiOeB+AwAdqxPs5D05AgB66KBriGBIPg/nRj/HVYdsSEcJk4tm8e 1VcXZSOYKMnN9rx0jgTdhsEmiLwd/NxRR3MBHLSbcET6V0oCbm+UZbX7PTTcKlDYdwlp c7USu2pRUS/7XVggD2ACrI+y4JXltZLvLtGUoZd2LEPjBXTB9jPcT7RBT1B3R21EpBpy xaNx9kHXMrdygs1iMKfWQ+ww1hI1O4n57Fo4X+g/UPSb0jfabIHlwx0SwnhCwQhqoiNk Jqng== X-Gm-Message-State: AOAM532OQ8l2CP61j8i8/nVz30qGpgH6AT7E2KCBJ/Yti5vAVDlLlIEu HhNSSjYAhHALSrXefB9qHhuNmA== 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 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+ X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Song Liu , Andrii Nakryiko , DRI Development , Daniel Borkmann , Kenny Ho , "open list:CONTROL GROUP \(CGROUP\)" , Brian Welty , John Fastabend , Alexei Starovoitov , amd-gfx list , Martin KaFai Lau , Linux-Fsdevel , Alexander Viro , Network Development , KP Singh , Yonghong Song , bpf , Alexei Starovoitov , Alex Deucher Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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