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 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 C1F4BC43460 for ; Fri, 7 May 2021 22:31:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 90B8161410 for ; Fri, 7 May 2021 22:31:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229864AbhEGWcL (ORCPT ); Fri, 7 May 2021 18:32:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbhEGWcJ (ORCPT ); Fri, 7 May 2021 18:32:09 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BB5DC061574; Fri, 7 May 2021 15:31:08 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id i23-20020a9d68d70000b02902dc19ed4c15so5234086oto.0; Fri, 07 May 2021 15:31:08 -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=I0YWXNTKMAQEd6z039aM9XkewcEru+auENvSRDSVALM=; b=ZLVjAoadVZr1dEm4/yvhnrf8/J/nef7G15JbUbGrTvaphSPPg1NYoxyWbrvVrYSS1h zIa96XTY8P0hpQ+yNemDEgMJuSG/c4WCmiNe6Nc+iCnLydkMAsdGrWvIm/17ma5Z4yM/ YzsvyYwW+WiotmISk+eiR/i8Cd7aUBrZpHgxnpBYVJ84BXnaaMaWQ2eKqxevUizYrrdW YbtS/h3evHXgpLsmcR18uUbQaKsFRYpehUV3Ng/5C9YykCWFXuYzVQL41A0Sr+comc9P aI9Yzg1U+9hzWSAs+VHaET9OhHIE/EcNaIBsMQFPLcf6+DcdHyLoOGNPJ3nmswEFT8wv svyQ== 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=I0YWXNTKMAQEd6z039aM9XkewcEru+auENvSRDSVALM=; b=Vfinu1tiKSfbT2HgkuLUh/RNaRjLZOTXwYIq9dUy+oHugPYJ/nn4t7XtwX5n6cZ0VP AtT/ErTwnq+bWVZw+IAm1x2MLe3AJttM+jqk3R+Xzd5ITsR3SU9caFF1a4wfE7dVbRri /Mn1vdPM0tSie4yW97HpK0dsCBxPrI2cBTnU+/ATQWc+ZVM9fuJC2PLap2hXXtKVeCLt 7ybj5YOpsDR2SITck9vpG6HdH9fUg1zgiaq/Ea7FbH2AcWjpFSQL3cWM48AsKi9ODrQn iRCrLKR8AsY7dEaQuNQfr4/0w1PIpVnq/c7nyLj0BXp9J27G4buKDJC1eCDLrgaWBECi gbcw== X-Gm-Message-State: AOAM531rHP/CKo+Zq5PKlXzvqN3YZkijNA8/eGWxA+N49gOfcoKS1mx+ TQ6oTARKtljW7QHcX3T06zfwi162wPk5YDqI6lEmUvvX X-Google-Smtp-Source: ABdhPJz6COeoWlO2jYoVGMFtMym8VH6Ykqhm4Rnoo8nk0d6rsnG/F5mHf4daWpwa7y0jBo0WQH9c2O2bb827AYiZUvk= X-Received: by 2002:a05:6830:1f12:: with SMTP id u18mr10532939otg.132.1620426667759; Fri, 07 May 2021 15:31:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Deucher Date: Fri, 7 May 2021 18:30:56 -0400 Message-ID: Subject: Re: [RFC] Add BPF_PROG_TYPE_CGROUP_IOCTL To: Tejun Heo 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, May 7, 2021 at 4:59 PM Tejun Heo wrote: > > 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. Maybe we are speaking past each other. I'm not following. We got here because a device specific cgroup didn't make sense. With my Linux user hat on, that makes sense. I don't want to write code to a bunch of device specific interfaces if I can avoid it. But as for temporal vs spatial partitioning of the GPU, the argument seems to be a sort of hand-wavy one that both spatial and temporal partitioning make sense on CPUs, but only temporal partitioning makes sense on GPUs. I'm trying to understand that assertion. There are some GPUs that can more easily be temporally partitioned and some that can be more easily spatially partitioned. It doesn't seem any different than CPUs. Alex