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 DDB3FC001DF for ; Mon, 31 Jul 2023 11:00:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229730AbjGaLAT (ORCPT ); Mon, 31 Jul 2023 07:00:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230412AbjGaLAP (ORCPT ); Mon, 31 Jul 2023 07:00:15 -0400 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61D57E40; Mon, 31 Jul 2023 04:00:13 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5222c5d71b8so6409101a12.2; Mon, 31 Jul 2023 04:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690801212; x=1691406012; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=f0ZOvY/Xpr5zHXbVwVBZloVfJ8G8FuuDZCTbV8z9EOA=; b=rH997djt343XybxXVBV+uA0CT9/skZz1zl6AUqtYMfTepAhSK30GnxKvmO4yoKPYYz hnjki4wYcBX+3CdzG7u+09ySzk2ZuKO0WR3ynbk46LfhoUGX3BqFkg8WjgNtC4XDI/A4 hbWVK4ZPCphdTdXL+/Ns+pkjRg5Gaz+2FshCJ51XoVlFmVshuZmyL9sNMIq9yuuNPqPl Jms53b74uOPrTI+pxyUusWF6dludQQW/2ZecBGJem6LETbdvQpR4GPmaiHEwSOKQAgEO NjEOxgen7eugWN5X6Pa0Jf7fpbDOQmmZ35uW4PYR+xPTGHOfNqQYmHhLr/f+IwPbWLxs YBQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690801212; x=1691406012; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=f0ZOvY/Xpr5zHXbVwVBZloVfJ8G8FuuDZCTbV8z9EOA=; b=MoZ1asJ5565cf+gP1AgS1JfDEBwGPMN2luUoACG7jftQxL5SweeHJ1H4/0j2HiMJIN 817MZtdlDgU32Zn5GhuDEdMH9D6okij7VCqcTZNH0ZJTGaiwEUK2e7BFfGqHq8jgdVTm Km3stGF0cDJebaQqXCgbSmz3I45a9pPL3osIj0qqXaWbY5IebSKV+MtYMIjtcQs3YBVM vCN+BdX0sdoXRAP40lgtTLRqfGSaYi+UD8feCamHdF3GrrpvNQmqGhcyHWFbHBZTdCz7 6tXepb8b9+06WJt9Z5MjKUuwxhutN97jhQZL1Ppzk8ZRYb6eC7DKsXM0ObPrYawDdpl4 n4Zg== X-Gm-Message-State: ABy/qLadGyDeRpnvI427EVrt8cGK+zcUzLJFI3AIdRtTDSoWNT0ilSym 6OdX6KyCG/v9y/snXAUXlA92KaRHQSbHlsb7Mko= X-Google-Smtp-Source: APBJJlEvzB3AzJ/tG+b0S8KLUVw6iL3Bw2nnGad8E+g1GQ8IQvLcu2BlyGA3ZVDjaEJxmRry1M5WYsjqAZIYec3ZxO0= X-Received: by 2002:aa7:d745:0:b0:522:289d:8dcd with SMTP id a5-20020aa7d745000000b00522289d8dcdmr7624694eds.35.1690801211659; Mon, 31 Jul 2023 04:00:11 -0700 (PDT) MIME-Version: 1.0 References: <20230726121618.19198-1-zegao@tencent.com> <20230726121618.19198-2-zegao@tencent.com> <20230731093655.GC29590@hirez.programming.kicks-ass.net> In-Reply-To: <20230731093655.GC29590@hirez.programming.kicks-ass.net> From: Ze Gao Date: Mon, 31 Jul 2023 19:00:00 +0800 Message-ID: Subject: Re: [RFC PATCH v2 1/3] sched, tracing: add to report task state in symbolic chars To: Peter Zijlstra Cc: Steven Rostedt , Namhyung Kim , Adrian Hunter , Alexander Shishkin , Arnaldo Carvalho de Melo , Ian Rogers , Ingo Molnar , Jiri Olsa , Mark Rutland , Masami Hiramatsu , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-trace-devel@vger.kernel.org, Ze Gao Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-trace-kernel@vger.kernel.org On Mon, Jul 31, 2023 at 5:37=E2=80=AFPM Peter Zijlstra wrote: > > On Wed, Jul 26, 2023 at 08:16:16PM +0800, Ze Gao wrote: > > Internal representations of task state are likely to be changed or > > ordered, and reporting them to userspace without exporting them as > > part of API is not a good choice, which can easily break a userspace > > observability tool as kernel evolves. For example, perf suffers from > > this and still reports wrong states by this patch. > > > > OTOH, some masqueraded state like TASK_REPORT_IDLE and TASK_REPORT_MAX > > are also reported inadvertently, which confuses things even more. > > > > So add a new variable in company with the old raw value to report task > > state in symbolic char, which is self-explaining and no further > > translation is needed, and also report priorities in 'short' to save > > some buffer space. Of course this does not break any userspace tool. > > > > Note for PREEMPT_ACTIVE, we introduce 'p' to report it and use the old > > conventions for the rest. > > So I really dont much like this. This looses the ability to see the > actual wait state flags, there could be multiple. Eg, things like > TASK_FREEZEABLE gets lost completely. Also, IIRC, TASK_FREEZABLE which is defined as 0x2000, is already lost in the current implementation of __trace_sched_switch_state which limits all states except PREEMPT_ACTIIVE below TASK_REPORT_IDLE to be reported. So I do not believe you can achieve this by just leaving things a= lone. Regards, Ze