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 9F13CC433EF for ; Tue, 10 May 2022 21:56:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235549AbiEJV4X (ORCPT ); Tue, 10 May 2022 17:56:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235185AbiEJV4N (ORCPT ); Tue, 10 May 2022 17:56:13 -0400 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF41957117 for ; Tue, 10 May 2022 14:56:10 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id m1so409188wrb.8 for ; Tue, 10 May 2022 14:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IwUgKUFNj7ibkuKWy6cspfPFQL3X6FyIq81DUZlFReI=; b=pvu4vmnNkxBfNPaw9v92a2w+TVqfwi+iTgvjgFvjq+ssgXnL2/XxuczeCjzFigw6Fp LdrwiJrm5va3fTljcIrhm2cCN2U3mHlAeGm/YCKUXs8GdTX9I68G+Bkv1+NDR1Vt5YAL b0Oy+hcWXfNh68+frvkkZEUFC4PBzALS5U5cfl6+gErj5JV6cqdOWZypd5vUtHNf1ZvG S5ld+Bo59W0iXbrlJP/mnDfnhgKqL6sJExvTb1S/4mzhTBYEDX1kSPUfTU+4U7XvOULp BlWx/yzcaO3KNO9uZIsiptBfq34GgjqYlMOzrHkqYyBggfOuj6Q3k2CYVGzEXWLPerlF PpIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IwUgKUFNj7ibkuKWy6cspfPFQL3X6FyIq81DUZlFReI=; b=3/ZD2lqeAj5/vFYCA00393LGCFYrnUdBC00jfr7Lt6TkNDMT9hh38pVaW63U9QAwBu QKqmrssd2C9pLB4MXkPw/QfdkzKXzs2miWvgimmqOx01Za+ipt3VJFOYOZgCDFnMLzSM jnVK8fOCa+cuW533TI+pVTOvBN1ZIjgNblM3NN8/V2BNzQkL53oSpbFPom8ttjAhtRcR I4E6Y2x3X+B2Ea+eyLk5ahc4qVHtp76tcU2TNkb74dbRT6vDVFVCWihCHYIUFGmwGiir Y4SOzBT9hz8e/sRzkpBw5RkK3zZiKLAUTE76aOakL/eD4rFHl0VysxBKis0/vk6UhJo0 /ZiA== X-Gm-Message-State: AOAM5314BtxRD2O0lnNLqW308eRk3ghLl+PnVO3Q5DPHQktyDJeet7VV HLIHTQ/4onTJEyyR6d2xkRggj6B15udO2/E433lrCg== X-Google-Smtp-Source: ABdhPJyvhf5tHo+7ymkHhZKRFq0olhspXHd8enDR9DXvVol++Jwbk6xZofLsCZBaS03E9VdsgNBSy5whbtz0QVbHtl8= X-Received: by 2002:a05:6000:154a:b0:20c:7e65:c79e with SMTP id 10-20020a056000154a00b0020c7e65c79emr20365907wry.582.1652219768969; Tue, 10 May 2022 14:56:08 -0700 (PDT) MIME-Version: 1.0 References: <20220510001807.4132027-1-yosryahmed@google.com> <20220510001807.4132027-2-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 10 May 2022 14:55:32 -0700 Message-ID: Subject: Re: [RFC PATCH bpf-next 1/9] bpf: introduce CGROUP_SUBSYS_RSTAT program type To: Tejun Heo 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022 at 2:01 PM Tejun Heo wrote: > > 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 again for your insights and time! That's great to hear. I am all in for making the userspace interface simpler. I will rework this patch series so that the BPF programs just attach to "rstat" and send a V1. Any other concerns you have that you think I should address in V1? > Thanks. > > -- > tejun