Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1496613pxf; Fri, 12 Mar 2021 10:51:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJySv303omLP/P05Jd6NFtt1mYGDrLkV3IPdigEykiPKqw7s8aRS6nCXC4GaF6iqpopn1I7h X-Received: by 2002:a05:6402:50c8:: with SMTP id h8mr15655190edb.360.1615575090197; Fri, 12 Mar 2021 10:51:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615575090; cv=none; d=google.com; s=arc-20160816; b=mKGRvgBbZI23LImorwkhaqsPmdIOcD3sLeAlzPnEf/mIio4WTfTNME7wAdcE6zbBh1 84qqwZsiFpmBPt1hvbQKvLslw6UISIim46HAlNb5SI6docNPw1j7RKXVros6gdBmiqDy /bCl6OE0RCSAxjGid3nANszN+UQyZiEyVcE+1C4hpIckEhbmHPJMwWXYD9kUEmpsaHHC +25q43MEoIgRFNl5e0GRDlyV3g52puIKnLDT3YXjM/au86ahnt2crOjMxEKoNn9PDXqG /z9WYovsoD8vR0NN2cqG70PfVWmgUNaExBaKRP3CM3Isdd7g4uSEOdzKJ496czCYhWV8 ptZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=yn3oqd71OOPt7mPkgVizuOXRNVOmqtItPZLFB9+qKkw=; b=YCUlG/FuyjLDW3XS6nVvHodaPdVLeyY2mZKO/ty1/0+RMPEF5seYTaS6cGWQvYp2GF D7S9ZJpcAssGbpyWih9md5vI1A3ldeN9RHHERzpH9WqH7FLWziFIKAgRgT4xK/0WXCNu qBncTaF6IKGCyf8SUtUJeKp1mkiAGp0H7c+SRswiEV3fXzYr5Et0WaeNr1BWFqywbxBq UNbdVjLLs7m/Rms5AQxQ4Zo7fzV+VrxXKNwqL4mZfkFlT/3FQNrmTx7wAixaoUAwjy2g ivHlsghJYxZRVO/SDWEalSnNADkaHlVlrjg7PiE47ypFo3SaW9NhiiLhxUCP5Ra8Oboz tNGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=11lbXaZa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si4548201ejw.185.2021.03.12.10.51.07; Fri, 12 Mar 2021 10:51:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=11lbXaZa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233581AbhCLSrv (ORCPT + 99 others); Fri, 12 Mar 2021 13:47:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:48286 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233833AbhCLSrT (ORCPT ); Fri, 12 Mar 2021 13:47:19 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D7ADC64F69; Fri, 12 Mar 2021 18:47:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1615574839; bh=2uFjKfwKbLyw+Q48WFWexw++e7YWReq36hDzFWGURzM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=11lbXaZazkSyO8mzf6Bd3Q81q09SN6oY8X5PSMkC3ViyDi9hfVyA+/DyKwHWT0uom ItvIE7ISsTaeNyEvQC4oWEIr82aoFbEPRlrIbEAVyFuyUYoy8aHStwY0Vovj/MFpuE CtGeoI1uBgBQ0tj3jrunP7BnZTbM9SdaQU741DeI= Date: Fri, 12 Mar 2021 10:47:18 -0800 From: Andrew Morton To: Jim Newsome Cc: Oleg Nesterov , "Eric W . Biederman" , Christian Brauner , linux-kernel@vger.kernel.org Subject: Re: [PATCH v5] do_wait: make PIDTYPE_PID case O(1) instead of O(n) Message-Id: <20210312104718.0685c3902fd0d22915aeacc6@linux-foundation.org> In-Reply-To: References: <20210312173855.24843-1-jnewsome@torproject.org> <20210312102207.a347e38db375226a78cc37bf@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 Mar 2021 12:39:12 -0600 Jim Newsome wrote: > On 3/12/21 12:22, Andrew Morton wrote: > > > > Could we please see some performance testing results to permit us to > > evaluate the value of this change? > > Sure. I've been doing some ad-hoc measurements with the code below. It > forks 8k children and then waits for them in reverse order (forcing a > full list traversal each time). I'll need to reboot a couple times to > get apples-to-apples measurements on bare metal, though. I'll plan to > run with NUMCHILDREN = 0 -> 8000, by 100. > > Does this look like it'd be sufficient, or is there more you'd like to > see? The current form doesn't use ptrace, but I expect the results to be > similar; (maybe more pronounced when tracing threaded children, since > every thread is in the tracee list instead of just the group leaders). A very specific microbenchmark which tickles a particular corner case is useful, as long as there's some realistic chance that someone's workload is adequately modeled by that test. Also very useful would be some words which describe what led you to do this work (presumably some real-world was being impacted) and a description of how the patch improves that workload (or is expected to improve it). IOW, please spend a bit of time selling the patch! What is the case for including it in Linux? What benefit does it provide our users?