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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B5D2C3DA64 for ; Sun, 28 Jul 2024 21:19:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96DFA6B007B; Sun, 28 Jul 2024 17:18:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91D3C6B0083; Sun, 28 Jul 2024 17:18:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E50A6B0085; Sun, 28 Jul 2024 17:18:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 63B1F6B007B for ; Sun, 28 Jul 2024 17:18:59 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E1ACD1C06AE for ; Sun, 28 Jul 2024 21:18:58 +0000 (UTC) X-FDA: 82390426356.18.032B612 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf04.hostedemail.com (Postfix) with ESMTP id 9C53640003 for ; Sun, 28 Jul 2024 21:18:56 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LHAyydsJ; spf=pass (imf04.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722201484; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=p+wn079PYg7GE4Z2FMCZuTF8ldh4mxPK9a38/BKbOd4=; b=EOsMT7ugzROO7iDKMOpFw2DhFiL8rSZVZDXg/EgqkEhBPDFsGZu+S1Snp6GGYpk4gPqvxM FTBGGiZkj9eIJMBa2O6nkbGdJwox6BNqQwZWXJXQjnTxggv0NG8rVAgvnLaMlkaqVmi0r4 9sGfariNlKMOsUjXfWMVKB7xcnSKdls= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722201484; a=rsa-sha256; cv=none; b=BL1Q5dMUNWpMnKhALYiuHIPUOBgDpTkV0XwnihLcBX6QHrKk/zMI94tNRgHj0MgnGQn896 oZ9mLObU0LcQcEBv/Vz3UKXXMaFg0FhzRqo8RViB5pfxB6vdG/CvEPdQqE9+tHWfRURFr3 E0UfDd1jMXnNNXl9isxzLrnhxXsm16w= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LHAyydsJ; spf=pass (imf04.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id B963BCE098C; Sun, 28 Jul 2024 21:18:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9CF4C4AF0A; Sun, 28 Jul 2024 21:18:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1722201532; bh=p6ipjOvVqF6sbK1Vn/wHSaHvySBYHhkhbaqXeUP2Q04=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LHAyydsJalWoIjxDSMRu97+wFnQ1QVowDjGpa2JbcKo1Gq+JQNt9koZYp5n6dSXCv w5o6M2ftH42gXMsygOgd0M89g1rbIE8/+eDkBQHxceQF+QrlDFwxLrtHuj3rhmCxjm AnHuEU1nA/FAV246WRA/MApyVW/lqsNZiEPQfCJk= Date: Sun, 28 Jul 2024 14:18:51 -0700 From: Andrew Morton To: Adrian Huang Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Uladzislau Rezki , Christoph Hellwig , Baoquan He , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Adrian Huang , Jiwei Sun Subject: Re: [PATCH 1/1] mm/vmalloc: Combine all TLB flush operations of KASAN shadow virtual address into one operation Message-Id: <20240728141851.aece5581f6e13fb6d6280bc4@linux-foundation.org> In-Reply-To: <20240726165246.31326-1-ahuang12@lenovo.com> References: <20240726165246.31326-1-ahuang12@lenovo.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9C53640003 X-Stat-Signature: hxof5kyjfzidabuen1xb5nogpqh7zti7 X-HE-Tag: 1722201536-244616 X-HE-Meta: U2FsdGVkX19e0xoWAQTNojbr2Ynl1+U/vo4UcRIg1FNuwzJSH42ap5zTov5ok5i6DwUk/rmRd+PR3S9nwQRwPxkKdpZcRqLItBQr9yYa62UmIZvpgRxhO5rI6W6+U7B1jEspb5X+IwUr7DQm5diXw/FiTy8zJTPbn0Mlaa9VVtGxXICC7NGLD239xNAQk3Rk6tBJ/CpFqGaDCM/mwQ9/8WhQQvu+Jp+Ejh88Izs4Oyr41writUqn7RDou4JMWNW18Neb7W4XMN0hLJCkfPuzcTDY+0DoRHBsTeAmMomj9d9MQ9fDmqc6O+f0L21NcN9I3KikwyyE2K7m+ioND7jGmEuKlRx2Yf1eAQ7YMeHUTXRdA3410uzJqHgfXGChkffjoe9AvFKP+FtRyVWP/Eixp+WiVQnfIj25SKQoiRfZlb2WoiRGlhH1LqDx2GTOb2eqSWP/koQSAoyurvae5K41V7M5wzJ0Q7V9iKY0BTpYT++M1RIxNdJ29hnbWlt/ODD1MtbtmYjuNskZnX4IEgag4xBVQQJ0bE5XAYBv8lXKvS5f4VugZMZqPwVV8tNADNfPBRD9lw8fl3ujzRdC0eZYVvJflVkTgXvohbGWPVNayjdS46rmdTNhd2C4KSqU5xaO2GeMfPnUWM7tGua5GeZ2Ft79rUmRHpuq1TX1HuiJf1/D/Fonsvy5R03j7L8WPcE37wUfp72nDqwIvP1FSUzoCyyBdcY0ynGxfcAkDXm41R9fqqX4JokMyldkLZ1SrW4bsYtSOSB0RF1chVN/QRfHNv3BLm3m74xYQCNIkMHyw85lrfuNZbvTezU/jCmE2Wi/utxvvW7u90SSSrTSG3/Xgu8vKSJQua3p2wYfdyC1X7tLI1do51X/u4DebuSjXUsPbDW1mksJQ4jzeOvkGoHfcghS/Z815zVuMdFVmE2xrP9LCCloXxLU5T/0JGlUDxDlF3m5y4jNyTZnsMRA+Pg QrfFnnVE Hmk6xtpt7qCNIMCRYaacMuRX4UVGdyMMxC+9Fv27HIwK8CVkT4AXPd9MmeRXA1wgr4/5cDGkdhDxpaNjpr6j03RWg+eCACtzvU7xCsWUljJHLsCf9rriqofrB8eQEWmVHFriXlaNwl0h99yKYK9OmZHdJd3xS7breBxNLK/0rJGTQDZTx7PuMmsDdjxTtplFemro8f+9/5D1nULGzPjhe2CowTsMmVSfKLiYPZW9GjznCaLGwL/IzG02FMQ5vQYM/JecPnLMYSYAZQiVsNV83vRC1tvvoslFmYAPBMqFXA0kTYk2poKimdzot6M75tGZ5qJelfUaxy3JNuBXThuwbpTUo+Q== 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: List-Subscribe: List-Unsubscribe: On Sat, 27 Jul 2024 00:52:46 +0800 Adrian Huang wrote: > From: Adrian Huang > > When compiling kernel source 'make -j $(nproc)' with the up-and-running > KASAN-enabled kernel on a 256-core machine, the following soft lockup > is shown: > > ... > > # CPU DURATION FUNCTION CALLS > # | | | | | | | > 76) $ 50412985 us | } /* __purge_vmap_area_lazy */ > > ... > > # CPU DURATION FUNCTION CALLS > # | | | | | | | > 23) $ 1074942 us | } /* __purge_vmap_area_lazy */ > 23) $ 1074950 us | } /* drain_vmap_area_work */ > > The worst execution time of drain_vmap_area_work() is about 1 second. Cool, thanks. But that's still pretty dreadful and I bet there are other workloads which will trigger the lockup detector in this path? (And "avoiding lockup detector warnings" isn't the objective here - the detector is merely a tool for identifying issues)