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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 437BAC433F5 for ; Tue, 10 May 2022 21:02:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231157AbiEJVCC (ORCPT ); Tue, 10 May 2022 17:02:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235548AbiEJVBg (ORCPT ); Tue, 10 May 2022 17:01:36 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6861FA6E34; Tue, 10 May 2022 14:01:35 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id x88so330886pjj.1; Tue, 10 May 2022 14:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=j3rcz6qVNZi20/uUbB9766ZMC6kcEWw22DciqK9/zDQ=; b=M5ccWIy7d+bh8DqBj2aI3HFZZKskE0cwfDgQq3SKLrVgdAEFxXFPBkEBMgJ4qngmA2 6H8woKrDHM1reouusOvd4aPscHfCRI6hEodeZJsd4D6vPzWpj+/ESYcRIaKuxdIo+A+Q REO2UUrR8BzAZBYQDBIpzFkYPdqzj+joI8K38ONynFtD+rXLjCemnJJiB6b4CFMkjshY CYR1R/+q+MdBzjd4wFuiVS17ecBinIwmowmWql+VGUH65xm+Uu8/uHde/uKwZ03XLtU1 905SUSDqeXRgRwg7ZHM6aBsoRSIR0O+RAeQn1ZgTa7JGGDNCVlqjo9fhIzsr4tSQQYUz Sx6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=j3rcz6qVNZi20/uUbB9766ZMC6kcEWw22DciqK9/zDQ=; b=PuKCPaS0HAsSgcgGWarDJAeAuq/XZCODbc8Y8ueM9uOubhSOSuc2+yJsirFQ9Q/9H2 dbMPqAWwzqJSV+J3HgK1VY+ZChtMU/KchCUCnROPvmwljKmCUzWlGPPdiqtIYOFv9UIx jqFBeZknXRQtjtJp2eKiTUETqqJeIa+SZBC6zZsMAFu95wDG1OOC+FQxakRQ6yQxfdiR qxsd1j/Xi1GfBjLV5sCXBhT+yCzlrw+CtE2wVtrjofUvY0APfFPKh8XBJGNw0ELOEwpX bR21oPc/Wo6VdsMC6QCN9RNJ52TBKAAG/wrMB38chIpGu050hnnQyu8uoeLAlUkUN68j WDGw== X-Gm-Message-State: AOAM531m4bsLk/SaREZ7hMrUtGmAu1rpb18G2gWnYVHAYrvKW0xlcvy5 KgJYCHU4MU/RC1eQe3BRjwI= X-Google-Smtp-Source: ABdhPJy9jdEXmmo87FTb0xRrE+zHyYpgKETtEix579sUr19jNrUhpmBxb5moGjeyn6lcojK04HS9pw== X-Received: by 2002:a17:902:ce02:b0:153:bd65:5c0e with SMTP id k2-20020a170902ce0200b00153bd655c0emr22083797plg.160.1652216494792; Tue, 10 May 2022 14:01:34 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::4:6c64]) by smtp.gmail.com with ESMTPSA id j4-20020a632304000000b003c15f7f2914sm162632pgj.24.2022.05.10.14.01.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 14:01:34 -0700 (PDT) Sender: Tejun Heo Date: Tue, 10 May 2022 11:01:32 -1000 From: Tejun Heo To: Yosry Ahmed Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Zefan Li , Johannes Weiner , Shuah Khan , Roman Gushchin , Michal Hocko , Stanislav Fomichev , David Rientjes , Greg Thelen , Shakeel Butt , Linux Kernel Mailing List , Networking , bpf , cgroups@vger.kernel.org Subject: Re: [RFC PATCH bpf-next 1/9] bpf: introduce CGROUP_SUBSYS_RSTAT program type Message-ID: References: <20220510001807.4132027-1-yosryahmed@google.com> <20220510001807.4132027-2-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Hello, On Tue, May 10, 2022 at 01:43:46PM -0700, Yosry Ahmed wrote: > I assume if we do this optimization, and have separate updated lists > for controllers, we will still have a "core" updated list that is not > tied to any controller. Is this correct? Or we can create a dedicated updated list for the bpf progs, or even multiple for groups of them and so on. > If yes, then we can make the interface controller-agnostic (a global > list of BPF flushers). If we do the optimization later, we tie BPF > stats to the "core" updated list. We can even extend the userland > interface then to allow for controller-specific BPF stats if found > useful. We'll need that anyway as cpustats are tied to the cgroup themselves rather than the cpu controller. > If not, and there will only be controller-specific updated lists then, > then we might need to maintain a "core" updated list just for the sake > of BPF programs, which I don't think would be favorable. If needed, that's fine actually. > What do you think? Either-way, I will try to document our discussion > outcome in the commit message (and maybe the code), so that > if-and-when this optimization is made, we can come back to it. So, the main focus is keeping the userspace interface as simple as possible and solving performance issues on the rstat side. If we need however many updated lists to do that, that's all fine. FWIW, the experience up until now has been consistent with the assumptions that the current implementation makes and I haven't seen real any world cases where the shared updated list are problematic. Thanks. -- tejun