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 9145DC3DA4A for ; Mon, 29 Jul 2024 11:29:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2414D6B00BA; Mon, 29 Jul 2024 07:29:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CA516B00BB; Mon, 29 Jul 2024 07:29:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01B336B00BE; Mon, 29 Jul 2024 07:29:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CF6286B00BA for ; Mon, 29 Jul 2024 07:29:14 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 771ADA39A8 for ; Mon, 29 Jul 2024 11:29:14 +0000 (UTC) X-FDA: 82392569028.07.3B429A7 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf30.hostedemail.com (Postfix) with ESMTP id 81F5D8000E for ; Mon, 29 Jul 2024 11:29:12 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DCXxIqzw; spf=pass (imf30.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722252499; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ylub7aafKxlZMuv2JYZ4S/MrGVU3Si7xKcH11JwBeGE=; b=vQWBqRp5da6mqrPOdz6w2ae8suRJ9iF3nHOxtSZi6VYFpzLeVoTpfo5gRDaPeffmZ4PXBj 9nl71HgcTfJKPCCjnm+KsjD92l31eam+qip0JN13wsXBCzL4l7MPpYWz8fvPSSbohbCT6h efUMSoqXhdDCFxMvTpr5KEiqvvxx8qk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722252499; a=rsa-sha256; cv=none; b=ZVHVsfCeWSB08i9RCoQRSBZAB46hz8ABhLiji+jOfwY52chmkZHCDPC/f0LGNoioGcT1Zg AJadgcZuj+243BwWSHzPSNHwJ6n3CAaENuJ6aGfIXgoJnS5wCB2qxsDR0Qugfj+GmG5YdG txGAJNEKwMQ0GiMpy0Q3RzPkGszXqe0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DCXxIqzw; spf=pass (imf30.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-52f04b4abdcso5287031e87.2 for ; Mon, 29 Jul 2024 04:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722252551; x=1722857351; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=Ylub7aafKxlZMuv2JYZ4S/MrGVU3Si7xKcH11JwBeGE=; b=DCXxIqzwJz/78HtFvoneP2rhBg5QpBmXBmzhuqLXzRRVUs4SL81Ws7Buourg1h11g2 T8toGgrtBXKfbh73rZ9+Kpnnmqh1qvZtsMMBErrDafBQtnBExsegfvkl1IH2p9PCv/EB CvqIMvhukMOdyrcBTvROa9iRtAmH29HFfzojZlvKMWjUdeHhSKMm53p3Fv5P265tfsNw C5e6rl/iqO1sa5AwV7CET8RkafYoQHhy/hf97z5uWI4aR6ydwAAu+TAN36gAzrTjDeMU yLvr2FjKY27tY6UvM/eEdQEfsmS2cHy1oEkMjfkYN44IbnQutSX8gUvDeVFG6tAsE+D7 AeMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722252551; x=1722857351; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ylub7aafKxlZMuv2JYZ4S/MrGVU3Si7xKcH11JwBeGE=; b=gZLRPKVzxo4jiTIJ23ioqLfUn2NpvJedvIGyXiUg/5dAeUk9VSqLpPnVIpfSXUzGFS zUgJN0ymLoLDU3QjBPURX/+/eo7kexlwBMHGDcV/KM3JpQmVZ5B2gpXjecnAIBG6tkc7 amqWGzzRu4atDoZBAMSPAL304zgggJMQ0WXVf8lGjHlUO5A39Wl9/SEVppzKgb6qNvmy TSr8ZDSZRpPAbu6YD4BegoZ8JCIlonYnK+rkJZr5PW62lMq8CXDEC+s5fme6kVWU9EtS P+Nb1Lk/W3iDb/5VMoofytsj4MFT/oRZQcRJ6dUyEqffimizWJ9OSqtmM2KAm5ANn0fs LkPQ== X-Forwarded-Encrypted: i=1; AJvYcCU4HRffMtDDHc6UCpmQUXDDvDXkPZ2GqmovV8cW8J9nrPcUYWQtCTqlYWeD7F87lF89g1a9dHNlWpAZ33stu3c0jOo= X-Gm-Message-State: AOJu0YwiDZMw23DBuA6+9tiUXMquRzaEUtbvvdf/h7fxywHlPKEDlij4 bKhXGVubISA63HKG6w30is+nSNyopBuYmzJ6DKxQIZY9ASXSowFD X-Google-Smtp-Source: AGHT+IFVOTeTU5baFFhEMY0+WQeweKFqWyH8B35A61wPJ4+iHPqo/tiUA64k0mdt2DgG77BFvW1rbQ== X-Received: by 2002:a19:8c58:0:b0:52c:f12a:d0e0 with SMTP id 2adb3069b0e04-5309b27a656mr4548211e87.28.1722252550544; Mon, 29 Jul 2024 04:29:10 -0700 (PDT) Received: from pc636 (host-90-235-1-92.mobileonline.telia.com. [90.235.1.92]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52fd5bd11f0sm1452561e87.80.2024.07.29.04.29.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 04:29:09 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 29 Jul 2024 13:29:06 +0200 To: Andrew Morton , Adrian Huang Cc: Adrian Huang , 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: References: <20240726165246.31326-1-ahuang12@lenovo.com> <20240728141851.aece5581f6e13fb6d6280bc4@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240728141851.aece5581f6e13fb6d6280bc4@linux-foundation.org> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 81F5D8000E X-Stat-Signature: dhsqrnb8cht6igynqft9ewgmh7mgy78b X-HE-Tag: 1722252552-437612 X-HE-Meta: U2FsdGVkX194jUTuvzfXpX151zFlPVL4jJ8RR71sIsqluhQllaeF/mwLvQbcVDPJ7BJYeYp9vLLRZbrRHc8hHxWPiQmlU3BfKx7bF42RXr+K7t4+NXNdfkecsPki1jlAzIDOL+y7t3KQ5/WKyiLxSricBGc8tMSapgYxJ81JF+cwY2KM3xqAvQRH/zt4Op9HmSjDrNF6/EHwo/UwmCtR5VVjOh4udYG0HHpS2Ay6yZUvRxqU0P9AKVAPJVk00p0XMdX6ARv3A4lhQv8/Crh56R7gLOHKcy18XkCpkgMo5nijdOSnjeRY7Tnsi7EogU17ShwzHf3amYQFUYA5uPc8j7awQqg+BjeLjkgMTlrfBSs/IWQykjn+aLnARF9jc6E5gZmiMgURNfGuY22JMP73by8ChTrw4tNNHaafRFjkWTlbgEpeCzZYI6CpkcW0CwtYlCPIUPQiqC7iImbeqULFXVRPNQpS3h4bs/4BG7kgTW1kb+f0uN7BIA0/3odyyAQaWQqG9cT72Ou6iwQ7U4CDd2Ezbrw9ehbdepbsw5GMs3KUPXktbNf8cYCRWQ+j6ukQj5dqmPywh3mLcuzhsPH+ghnVRUeicV3bZbU6I/27W78l6tH+aHov4QYVrJjiyEIK8DGWrinNE/SvlDf+Bw97SnEzpm7H4pXK/04AfDTkbIySrd1SqpnIVzHc1s0Y/OhDehTHTXIX5ZISp6ywbIxG6Z0V0oRV+STZCAI0NvWqbDgvVyz0WHm9AiYx5CAC7EovvYh/5XWelvx6nim6nuEbaw2It+lq2cku3bcHfkeWFN0/FXVnoah1R874L5fz3wndwFNjrzJkIEgMPsZ3R2f4F9jNW9624Q/6WSKFqt5FxbQYt/IoKJnllb2rhAdUdnO46m3K6sK6dumDnj30qVzqwV7056kmA4CVXIXLNDr8bYGyC6j1cPtti/NLc5tIIvyWT9xCju+yUk4QjL8mHEv GDy5Xb8d fLjNoBBHbWzZ4962M/rlDJTetLjBzfkTgdF0FdDb0mOFVe5613OuZ4z4uIlngp+rRf6MVvPoL8Gj7O4vcxYrH8gKEBX0ens0sB/EGBdZ6wvqzBk5Kq/EwMd8kdA+2tE6oRjY+lATC7NGRvctZ0Av5y7oXS7cLupv8WBcjazMcw0wEc3EgvE5oRFTEAQxUoqNKjgy6fsl29i1/JMsOzubvKDusFPAPvZbAVjRlJbeFRm9zz2MSS7gVo6SWOt5Nexb9K4oAvpt9L4/JCg8Ti7+sKf5DcBlHSE3/8qBsrh+gUG448Gn9yv1QOT0g0JbAUowBuHx3FlEdgTW8+8rWPK6porICEb+2FMeDl0KsxUodETBric7l7S+e14GPp7WLNqidEmRGCLfqlEDp4eCTqs+XyYunrrluCi6Pv/u6m3m84Ahqya/6hgnNj30H7a0UvDX3yNcLTveCsACy/IJ9/gD4wktJA7v3BMOcQgWObgse3Qt6DMVB7ONT5TL+s6A94TZFdZ55G4KylVLbG+ZZSUG+ixwFykWBkfOmdnQWMmiHeBrSggg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000100, 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 Sun, Jul 28, 2024 at 02:18:51PM -0700, Andrew Morton wrote: > 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) > As for 1 sec execution and worst case. I did some analysis with enabling CONFIG_LOCK_STAT to see some waiting statistics across different locks: See it here: https://lore.kernel.org/linux-mm/ZogS_04dP5LlRlXN@pc636/T/#m5d57f11d9f69aef5313f4efbe25415b3bae4c818 It would be really good if Adrian could run the "compiling workload" on his big system and post the statistics here. For example: a) v6.11-rc1 + KASAN. b) v6.11-rc1 + KASAN + patch. Thanks! -- Uladzislau Rezki