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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 01BACC43461 for ; Fri, 7 May 2021 02:06:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B3D586113E for ; Fri, 7 May 2021 02:06:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233574AbhEGCHp (ORCPT ); Thu, 6 May 2021 22:07:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231288AbhEGCHp (ORCPT ); Thu, 6 May 2021 22:07:45 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67330C061574; Thu, 6 May 2021 19:06:45 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id c3so10606096lfs.7; Thu, 06 May 2021 19:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RusZqf2ICrM5fo1RSYd7Qden8l8w86x5qFZgmckN64E=; b=D3bvz8i81tQkrtuQ+d1bkqIKoTdXAZWYYo6Jfm6wspflRIADJqkHwK3Tng54nv8L8j kIUQ4Gd1GX0Mm3MGVRY/Cv0CqOQ2b/SwKrjuqKQ2ZLb42V5VpGDH8k9zdxW5F8jvJyfa oLTIlByZ21h77IN3GiYOi8DRoH5svGBcNiKp/hCtXMH1J7nhMihzdzDioSOcRJ0RARol OVt144Jx1rzUTkCU0vW3daSLf0owrtC0yAdtvCT57MQoOyn7OYD0UppOnItgNU2aQ3lA twFeOWFtx02nENFd16Y5AUuwOe/mWTYJiHeGA8pGRIoA8ogpgcLuy5gafsmAh3Y1WSVg /i3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RusZqf2ICrM5fo1RSYd7Qden8l8w86x5qFZgmckN64E=; b=dzuxIb/VclAj0yuogmf83ZBHjsGXgzGOAb+4ttOOxilWONS43VClxKPlgYsfkFF4u5 2k/Yu3C2OHTXpIbSRL0NbPiM6/TIB6teAXptwnX/A8a4nHCnKs4fcTAzotN3wNKZCrLE 8aUXNhEITHqlpU/dCNAhzO8NQ+pbyDARoePv7bF4fWaElOBEkXUBQHJx6YNSnqNT3StM UepwSojD7kTtujo8O8Wpcc7nDmFR9LqB5GpMpAMf7aqiPl/P9ydH/TeUOhXRt4oxeCDq Wb8tR2aCGLb/mPI1PBRtb67qXvduxNg65AoBuGRenGLjXTenPEc4QBtz8D91M65H4Acz 1TRw== X-Gm-Message-State: AOAM532XhTld0J+XddjiBblcuDXrtcRo36oLpmTsO/aFgzmROe1slAJq ZfheZ+YJVDtHfYxUr+U+ZMlfcRx7lLRh1XFfvk4= X-Google-Smtp-Source: ABdhPJy6fE0F0maDDYRJg2QRG950fLRhaA0QiW7C6vG6nsHx3tC0UfW9AmOOCNLGEB8W9gmuKKolcqYX/UZkgFF0HoM= X-Received: by 2002:a05:6512:c04:: with SMTP id z4mr4820989lfu.167.1620353203882; Thu, 06 May 2021 19:06:43 -0700 (PDT) MIME-Version: 1.0 References: <20201103053244.khibmr66p7lhv7ge@ast-mbp.dhcp.thefacebook.com> <20201103210418.q7hddyl7rvdplike@ast-mbp.dhcp.thefacebook.com> <20201103232805.6uq4zg3gdvw2iiki@ast-mbp.dhcp.thefacebook.com> In-Reply-To: From: Kenny Ho Date: Thu, 6 May 2021 22:06:32 -0400 Message-ID: Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL To: Daniel Vetter Cc: 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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. Kenny