Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp1287846rdb; Fri, 20 Oct 2023 14:09:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHMOJ08jSLoi95Q4CfKv8Vzy/CdeRbUPFLXEIEtuiXcpK52knbqdyD4aiczdAO2EiNfvjRw X-Received: by 2002:a05:6a00:248d:b0:6b2:5992:9e89 with SMTP id c13-20020a056a00248d00b006b259929e89mr3433929pfv.9.1697836144266; Fri, 20 Oct 2023 14:09:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697836144; cv=none; d=google.com; s=arc-20160816; b=YMQ2wF6NtzQ/KdUlWr//JEPe/Lcc6ZBwhyqJQP15lNgDQGF2XaqzCZ1K3mfG46mAhX AKzK8Bv070QndKYfDGCOA5hGofNJZQ7w08tOFT5hD4DbDRMEIF9Dbcs2MYWaXVb8xB6A STnBrydtYuvzSpYc1cGBFNNbfxUYfi6YKeD4/3fuvtSroge8ywV9jo+Ic1r3frLLOhM+ j+gIU5jj91x+Lm3v5g1pjnlkE6vYnPyr89KisYZ9CiMVpsjjMo5EijdgiMcCu3D2Sn8o F7BDaTfloW5r1tVWPdqDO7XWTse3MmEd0+DzkzVoI2kXOu4m4wz7azhhtNUTEWtlWG33 dXaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=02ISBYQc0p0Nt6JWDFM7LP+D2JK2TbEXYFFsH2l1nX4=; fh=E10VZPe6Co8ezsBgErBfA67AzM7mDmfOH0ZUqd+UkZw=; b=TRQtzK6hPgjdSIlJMY8sU23h2zd/z+WjAZbOITQjw61z5F1vtKgAKXWVCd8avjRZnL o45yoWPYWQDtVvRENfgyKsvseaB5+curUkYk+7qJ4mITf07UtStlbuZGqXEntt4Ce/Km gm2nIpkQVhLpmMC1xW5yWmX6ozP5RqBjH4+aXTCOhk67Hs+HnrIfO/2qUk2EaQMz7pre 2kBllv765PMM6NooAe9BM5uibFYE2Kuj3mJwJ91/K2t3YoJ9hZpCPSN0zB9Vv649l1Ts FOiLibsq+VVX8hsqbUxJo0reiuUXO5ysMbrTOMP/Ocg2xzflPBUZxMVJ2HVUa3oECgcm K95g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id d5-20020a655ac5000000b00565f01b9403si2403728pgt.883.2023.10.20.14.09.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Oct 2023 14:09:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id BC22882F306A; Fri, 20 Oct 2023 14:08:55 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233048AbjJTVIf convert rfc822-to-8bit (ORCPT + 99 others); Fri, 20 Oct 2023 17:08:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231875AbjJTVIY (ORCPT ); Fri, 20 Oct 2023 17:08:24 -0400 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D77A10C7; Fri, 20 Oct 2023 14:08:18 -0700 (PDT) Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-27d1373f631so994718a91.1; Fri, 20 Oct 2023 14:08:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697836097; x=1698440897; 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=rMQasgZjpOl1DCFinwfvRlcT3Yj5p5ETw7uv0PZtWMM=; b=FxsxZbfXueFAkIRz4x5l2J659W28JpAOQdLzmmRrhjjQQ78D51E1mxqZ6jZBCjabDR gKdk5CJ0f5ZL/N2re/M3bGGmooGtwllezIj8hLMo9KBMmcQ13skVersp+8HoXyNTANbJ /sboovUtkx3upt2w+9DDgp8WfJvTUmaBVf/mh8g1lom2hbmnNeJ3oNF80gOkCqswRDog MhSEOAfjo9XpaJpB4MmBe7AE61glo8/Csuh0WwIZQERZuYcMGGovRqeuhDxN0SCCa1ns ze//orVKvvEbjhibTkFu2sqzrFAXPZXshjClgMB0a5euZaGEALh+StSqeNMC2BQ+nYO7 cuqw== X-Gm-Message-State: AOJu0Yxz+BoQvMooM7BPfqjR/OVvtEgCm8YqBShIn8tR2pKTQ/Sm3O15 TPmDuWemNWYoHR5ZoT7hIbiN06qS57UzXA0Mz7M= X-Received: by 2002:a17:90b:a16:b0:27d:9bef:1454 with SMTP id gg22-20020a17090b0a1600b0027d9bef1454mr2849617pjb.22.1697836097337; Fri, 20 Oct 2023 14:08:17 -0700 (PDT) MIME-Version: 1.0 References: <20231012062359.1616786-1-irogers@google.com> <20231012062359.1616786-14-irogers@google.com> In-Reply-To: From: Namhyung Kim Date: Fri, 20 Oct 2023 14:08:06 -0700 Message-ID: Subject: Re: [PATCH v2 13/13] perf machine thread: Remove exited threads by default To: Ian Rogers Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , Nick Terrell , Kan Liang , Song Liu , Sandipan Das , Anshuman Khandual , James Clark , Liam Howlett , Miguel Ojeda , Leo Yan , German Gomez , Ravi Bangoria , Artem Savkov , Athira Rajeev , Andi Kleen , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 20 Oct 2023 14:08:56 -0700 (PDT) On Wed, Oct 18, 2023 at 5:39 PM Ian Rogers wrote: > > On Wed, Oct 18, 2023 at 4:30 PM Namhyung Kim wrote: > > > > On Wed, Oct 11, 2023 at 11:24 PM Ian Rogers wrote: > > > > > > struct thread values hold onto references to mmaps, dsos, etc. When a > > > thread exits it is necessary to clean all of this memory up by > > > removing the thread from the machine's threads. Some tools require > > > this doesn't happen, such as perf report if offcpu events exist or if > > > a task list is being generated, so add a symbol_conf value to make the > > > behavior optional. When an exited thread is left in the machine's > > > threads, mark it as exited. > > > > > > This change relates to commit 40826c45eb0b ("perf thread: Remove > > > notion of dead threads"). Dead threads were removed as they had a > > > reference count of 0 and were difficult to reason about with the > > > reference count checker. Here a thread is removed from threads when it > > > exits, unless via symbol_conf the exited thread isn't remove and is > > > marked as exited. Reference counting behaves as it normally does. > > > > Maybe we can do it the other way around. IOW tools can access > > dead threads for whatever reason if they are dealing with a data > > file. And I guess the main concern is perf top to reduce memory > > footprint, right? Then we can declare to remove the dead threads > > for perf top case only IMHO. > > Thanks I did consider this but I think this order makes most sense. > The only tool relying on access to dead threads is perf report, but > its uses are questionable: > > - task printing - the tools wants to show all threads from a perf run > and assumes they are in threads. By replacing tool.exit it would be > easy to record dead threads for this, as the maps aren't required the > memory overhead could be improved by just recording the necessary > task's data. > > - offcpu - it would be very useful to have offcpu samples be real > samples, rather than an aggregated sample at the end of the data file > with a timestamp greater-than when the thread exited. These samples > would happen before the exit event is processed and so the reason to > keep dead threads around would be removed. I think we could do some > kind of sample aggregation using BPF, but I think we need to think it > through with exit events. Perhaps we can fix things in the short-term > by generating BPF samples with aggregation when threads exit in the > offcpu BPF code, but then again, if you have this going it seems as > easy just to keep to record all offcpu events as distinct. Saving off-cpu event on every context switch might cause event loss due to its frequency. Generating aggregated samples on EXIT sounds interesting, but then it'd iterated all possible keys for that thread including stack trace ID and few more. So I'm not 100% sure if it's ok doing it on a task exit path. > > Other commands like perf top and perf script don't currently have > dependencies on dead threads and I'm kind of glad, for > understandability, memory footprint, etc. Having the default be that > dead threads linger on will just encourage the kind of issues we see > currently in perf report and having to have every tool, perf script > declare it doesn't want dead threads seems burdensome. Fair enough. Thanks, Namhyung