Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1556547pxf; Fri, 12 Mar 2021 12:31:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzhImuyz+iP2MHFGZaZIvfUlZcyekzTdgQkVGOp21WNxVeclEVpKIrpR9Xxdg1PGdNP2/Ei X-Received: by 2002:a05:6402:4244:: with SMTP id g4mr4746008edb.204.1615581087290; Fri, 12 Mar 2021 12:31:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615581087; cv=none; d=google.com; s=arc-20160816; b=GIqzk+79hnnQFNkwyloh6dRWRBHUqG8JWySaYV5uwK2aTg7+t9leMaCIb4gUZMEyla MtdDs0s40GZCvuxieJAay1fSANbjk6Kvt4kgGPXSs2xE5YYzn1sRKBBj1RiZhhiJnXdo H4cQHSJ61L4pDoAAsvmVHe4GDgIZiIXajLwh64NioNet5lhDfnrZDxRHkLwmb8Q7c/w2 MPaFlH39GkzHpyO2eP+8ebssWW6PA0eXkhc+zV/2uNCi9XLVmpBqbZ997rlRwUkB/+9o Lesexwc7yzBYgrRtnUuLJ29S51JUKBPpSKmvStfnhFAi7Gx9SdM8Cq5rh7skUyEld3se 4NkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:mime-version:user-agent:message-id :in-reply-to:date:references:cc:to:from; bh=LpNnI0GHbxRvGOsnFvpvR9vkaOJtTs3SBBm7XZK7szk=; b=PjXOKoYbzUVh2H9jSnzMlwQV/wNO8noE3fCaAKnB3MQZ0GCjP0QkhbqGFj5uqrCnDX uj4P2xGA1s07DtJo2JnN01S+qJd5cutuRPC+IaO0njz+75wltZU+72wrEO4LevpxQJOR NfzGiolTOjY5vT0vfcZDZw09G7d5vJW+YEIuKsGhKcC8EeMgvta21jXwKabLYXlNKQsX oYl8kfyb1fSvKijeXjfbAOwKUvczifIpOOG05Go4bypbiCN95agc+AgnbgGb68bDNi5I XijUBibOGzDLHERQSbB2kf8sMqur80F0mB8LF9g0BtAsvGRqCiE7VXRw63S3BAGIilft Ijcw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bs9si4797245edb.575.2021.03.12.12.31.04; Fri, 12 Mar 2021 12:31:27 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234772AbhCLU3s (ORCPT + 99 others); Fri, 12 Mar 2021 15:29:48 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:52704 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234673AbhCLU3l (ORCPT ); Fri, 12 Mar 2021 15:29:41 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lKoPk-0000qd-Qy; Fri, 12 Mar 2021 13:29:40 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lKoPj-006Zm2-Ts; Fri, 12 Mar 2021 13:29:40 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Jim Newsome Cc: Andrew Morton , Oleg Nesterov , Christian Brauner , linux-kernel@vger.kernel.org References: <20210312173855.24843-1-jnewsome@torproject.org> Date: Fri, 12 Mar 2021 14:29:46 -0600 In-Reply-To: <20210312173855.24843-1-jnewsome@torproject.org> (Jim Newsome's message of "Fri, 12 Mar 2021 11:38:55 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lKoPj-006Zm2-Ts;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/qwjM8dl0Gb1QwnotGtvTTQxD9aoOPQ9s= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa06.xmission.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_Symld_Words,T_TM2_M_HEADER_IN_MSG, T_TooManySym_01,T_TooManySym_02,XMGppyBdWords,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4991] * 1.5 TR_Symld_Words too many words that have symbols inside * 0.7 XMSubLong Long Subject * 2.5 XMGppyBdWords BODY: Gappy or l33t words * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;Jim Newsome X-Spam-Relay-Country: X-Spam-Timing: total 393 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 12 (3.0%), b_tie_ro: 10 (2.6%), parse: 1.12 (0.3%), extract_message_metadata: 13 (3.4%), get_uri_detail_list: 1.57 (0.4%), tests_pri_-1000: 13 (3.4%), tests_pri_-950: 1.24 (0.3%), tests_pri_-900: 0.99 (0.3%), tests_pri_-90: 131 (33.4%), check_bayes: 130 (33.0%), b_tokenize: 6 (1.4%), b_tok_get_all: 6 (1.4%), b_comp_prob: 2.1 (0.5%), b_tok_touch_all: 113 (28.7%), b_finish: 0.94 (0.2%), tests_pri_0: 206 (52.5%), check_dkim_signature: 0.78 (0.2%), check_dkim_adsp: 4.9 (1.3%), poll_dns_idle: 0.32 (0.1%), tests_pri_10: 2.7 (0.7%), tests_pri_500: 8 (2.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v5] do_wait: make PIDTYPE_PID case O(1) instead of O(n) X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jim Newsome writes: > do_wait is an internal function used to implement waitpid, waitid, > wait4, etc. To handle the general case, it does an O(n) linear scan of > the thread group's children and tracees. > > This patch adds a special-case when waiting on a pid to skip these scans > and instead do an O(1) lookup. This improves performance when waiting on > a pid from a thread group with many children and/or tracees. I am going to kibitz just a little bit more. When I looked at this a second time it became apparent that using pid_task twice should actually be faster as it removes a dependent load caused by thread_group_leader, and replaces it by accessing two adjacent pointers in the same cache line. I know the algorithmic improvement is the main advantage, but removing 60ns or so for a dependent load can't hurt. Plus I think using the two pid types really makes it clear that one is always a process and the other is always potentially a thread. /* * Optimization for waiting on PIDTYPE_PID. No need to iterate through child * and tracee lists to find the target task. */ static int do_wait_pid(struct wait_opts *wo) { bool ptrace; struct task_struct *target; int retval; ptrace = false; target = pid_task(wo->wo_pid, PIDTYPE_TGID); if (target && is_effectively_child(wo, ptrace, target)) { retval = wait_consider_task(wo, ptrace, target); if (retval) return retval; } ptrace = true; target = pid_task(wo->wo_pid, PIDTYPE_PID); if (target && target->ptrace && is_effectively_child(wo, ptrace, target)) { retval = wait_consider_task(wo, ptrace, target); if (retval) return retval; } return 0; } Since the probably needs to be respun to include the improved description can we look at my micro performance improvement? Eric