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=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 1DDC5C43461 for ; Fri, 7 May 2021 20:59:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D1DAA6145E for ; Fri, 7 May 2021 20:59:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230198AbhEGVAT (ORCPT ); Fri, 7 May 2021 17:00:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230093AbhEGVAS (ORCPT ); Fri, 7 May 2021 17:00:18 -0400 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 222B9C061574; Fri, 7 May 2021 13:59:17 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id q127so9941062qkb.1; Fri, 07 May 2021 13:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WM3qTdeeeQvN9wqJqOAh1ks+lZ+P1gcdIZXNpOTonrc=; b=r+Rn1FuazZF3GatZUdqZ9l+FO+YTxA1D3YJlPcigoUO/F7/3KKxnkKe8ET7nEtAaih h6fBoqyszKYVFnDS+WIP+vKhSBconGErn5q6t57LNyLRSMcUsTeSRHebj6zjsqnU8x91 x0LcaPNDgX8NgwJDE+oQh/NazmWbYdiuBHCUfHS5bzAcrnOI8eVAd750FcUke5aERvyk RyJfEPfKen91mYgLYXsAZnWv3MdAYzlzFwN7wIWnOJ841tOYm5RbkLFP9VKshPpvdoKI PnUzOkCTWO4flAD3dS69vOC0XZLegxH4D7oQ0YhZ3bJhNRecuxNpozapdS0JCFX0VV/K EdCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=WM3qTdeeeQvN9wqJqOAh1ks+lZ+P1gcdIZXNpOTonrc=; b=Rm6cV4AcgVr0g/9YbwdzM5XE3Pw6BHDCVhcO/VDK1DlXL8VMaXbd3riaSpeiDzVo44 pm9f+rWu6oCNhI9t31M7M2pYW2CwV/kRJVvuEWdlxrXJWsgpjiQZ7BS34mbP4WHZOL0G YWIiXN/4xOnNVYtzQoArrWKRqvbT7Yqs7qs29qGPj6F2XsH8b1thZG4hQwbo/PTUkLax a0NsGl8ZLMYbJw4bxl9NLYs39sDE1HiHIQ0nmm2N7ngvKG37ieV99wCQ1Wmn5GNKjfLN SELZNoz+zbLjTaietR2wjijQ+rY/RjyGp3KCc9s8z8KYW8hhUB9haV5qGg7Qe6NN1X0S 6tdQ== X-Gm-Message-State: AOAM532S+1AdQAa+NPVn8/cbN18DcPLYWAwijeEaTXu05D3JzQcS829a XllG4bPIk82ILYUo+5aQ3z4= X-Google-Smtp-Source: ABdhPJxyjJaPUgZZ5DfuESF5Im6k2ukuj2Fa/7dXtcMZSkR/HegPBCpoXKWS0kZr+E66ksFX99ZGJQ== X-Received: by 2002:a37:8c1:: with SMTP id 184mr11654363qki.345.1620421155940; Fri, 07 May 2021 13:59:15 -0700 (PDT) Received: from localhost (dhcp-6c-ae-f6-dc-d8-61.cpe.echoes.net. [199.96.183.179]) by smtp.gmail.com with ESMTPSA id e13sm5982704qtm.35.2021.05.07.13.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 May 2021 13:59:14 -0700 (PDT) Sender: Tejun Heo Date: Fri, 7 May 2021 16:59:13 -0400 From: Tejun Heo To: Alex Deucher Cc: Daniel Vetter , Kenny Ho , 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 , Dave Airlie , Alexei Starovoitov , Alex Deucher Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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