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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB7D5C433E3 for ; Fri, 21 Aug 2020 01:42:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94A62208E4 for ; Fri, 21 Aug 2020 01:42:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94A62208E4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D70C98D0002; Thu, 20 Aug 2020 21:42:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF9B76B006C; Thu, 20 Aug 2020 21:42:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE8C18D0002; Thu, 20 Aug 2020 21:42:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id A53DC6B0068 for ; Thu, 20 Aug 2020 21:42:35 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5D85D824556B for ; Fri, 21 Aug 2020 01:42:35 +0000 (UTC) X-FDA: 77172876270.24.sheet70_5b14a5827035 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 366B51A4A0 for ; Fri, 21 Aug 2020 01:42:35 +0000 (UTC) X-HE-Tag: sheet70_5b14a5827035 X-Filterd-Recvd-Size: 2662 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 01:42:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DCE4CB1E7; Fri, 21 Aug 2020 01:43:00 +0000 (UTC) Date: Thu, 20 Aug 2020 18:27:50 -0700 From: Davidlohr Bueso To: Qian Cai Cc: akpm@linux-foundation.org, catalin.marinas@arm.com, oleg@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH] mm/kmemleak: rely on rcu for task stack scanning Message-ID: <20200821012750.qxiklfhuaryajvhn@linux-p48b> Mail-Followup-To: Qian Cai , akpm@linux-foundation.org, catalin.marinas@arm.com, oleg@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Davidlohr Bueso References: <20200820203902.11308-1-dave@stgolabs.net> <20200821002554.GB4622@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200821002554.GB4622@lca.pw> User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: 366B51A4A0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 20 Aug 2020, Qian Cai wrote: >On Thu, Aug 20, 2020 at 01:39:02PM -0700, Davidlohr Bueso wrote: >> kmemleak_scan() currently relies on the big tasklist_lock >> hammer to stabilize iterating through the tasklist. Instead, >> this patch proposes simply using rcu along with the rcu-safe >> for_each_process_thread flavor (without changing scan semantics), >> which doesn't make use of next_thread/p->thread_group and thus >> cannot race with exit. Furthermore, any races with fork() >> and not seeing the new child should be benign as it's not >> running yet and can also be detected by the next scan. > >It is not entirely clear to me what problem the patch is trying to solve. If >this is about performance, we will probably need some number. So in this case avoiding the tasklist_lock could prove beneficial for performance considering the scan operation is done periodically. I have seen improvements of 30%-ish when doing similar replacements on very pathological microbenchmarks (ie stressing get/setpriority(2)). However my main motivation is that it's one less user of the global lock, something that Linus has long time wanted to see gone eventually (if ever) even if the traditional fairness issues has been dealt with now with qrwlocks. Of course this is a very long ways ahead. This patch also kills another user of the deprecated tsk->thread_group. Thanks, Davidlohr