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 20CC8C7EE23 for ; Fri, 19 May 2023 14:13:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E04B900004; Fri, 19 May 2023 10:13:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99044900003; Fri, 19 May 2023 10:13:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8587D900004; Fri, 19 May 2023 10:13:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 77C97900003 for ; Fri, 19 May 2023 10:13:48 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4F2974034E for ; Fri, 19 May 2023 14:13:48 +0000 (UTC) X-FDA: 80807198136.04.E366FDA Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf10.hostedemail.com (Postfix) with ESMTP id 8671EC0021 for ; Fri, 19 May 2023 14:13:46 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=M7JUkFlS; dkim=pass header.d=linutronix.de header.s=2020e header.b=62EW2RYR; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf10.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684505626; a=rsa-sha256; cv=none; b=zWOIBOdL7Wm5Z73GjRwbPsEuhSLP7uTSm0B7MsxH/o7VbLBBQlUOEX5Ceg9N/MSw/QloaQ eTiPYmPJMUfsLPobkkProMey3bcgVqCMxwbFl6XISM30dzQyKgUP1FbWB2uWAVISV62VRw JCcbi9BA1Spsx9AgH8ofBKKzAnWP8os= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=M7JUkFlS; dkim=pass header.d=linutronix.de header.s=2020e header.b=62EW2RYR; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf10.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684505626; 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=Cf30QsArGlvD7J2wXvNnYAEQk2qn+mQ9OE81QDm7yEw=; b=nRnsicvYDSFY20MPTGbv47grrkDnWKi1e+cf0LNChDM4NyrCvFpfZeUt59liSqX8144/r+ 9iQbs9MW4kSMY4Qe98xHxY0RifDyB+NFBmQ5ozzpK9hqnj/pYmnVpdncEZD9RqOmgfleo9 R6s3FXhKD6Jx5hvAdpswuprYzbHBUo0= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684505624; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Cf30QsArGlvD7J2wXvNnYAEQk2qn+mQ9OE81QDm7yEw=; b=M7JUkFlScgAHLKCbUeZuMy1Awt7SXaQD2H5F0k7ZkYgjIVjuyKak2oEW+O6tM/OpQg+wiI EflZhsDMPJVIfAQbEXQdk620cFMgLJcMQjBxb3TJQkmlNyYMMLAzNn6D6awOiDc8wX02ws 0V4SM1efp5qZlF+f+VQMLsIK2+L6i/N64ReSNYVoW1rLgB55JOmnjkfFoaIJiE8QerOOTo BFgU15aonVxQZ+OYlcEbhsi2vk8f8oXFL+jJbtRMfa9yAtQjfqTHeta4q3ihYasaK4/bmK elpI8fhKNTpKO9WjiaHEBgX3QBAUFdm4jSl41Bmc/imt6t3XOUy5aqiYtcQRUQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684505624; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Cf30QsArGlvD7J2wXvNnYAEQk2qn+mQ9OE81QDm7yEw=; b=62EW2RYRJ2LMSby3ZKwRctvzyIV0IJLjjxf+uVz1bggPghrCk6rIXaDo86zS5mbe+6w2mF 2vrTZv+S2QeKKCCQ== To: Baoquan He Cc: "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges In-Reply-To: References: <87ilcs8zab.ffs@tglx> <87fs7w8z6y.ffs@tglx> <874joc8x7d.ffs@tglx> <87r0rg73wp.ffs@tglx> <87edng6qu8.ffs@tglx> <87y1ln5md2.ffs@tglx> <875y8o5zwm.ffs@tglx> Date: Fri, 19 May 2023 16:13:43 +0200 Message-ID: <87ttw84dew.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8671EC0021 X-Stat-Signature: rskqtro3t38asqhd59wneb51nkkh5tu6 X-HE-Tag: 1684505626-271112 X-HE-Meta: U2FsdGVkX18X/q9y1jbagZFzqZ5oRhaDIIjj1deIZxF28xBVaddpDQTQL3l5D+7yh5Y7QQYrZ8p/bk4hZr+86U9ddrdqQGk4F8U+WUN6aOjxZ3DdxGfl7QgvRa3SaWXVeag3Dm25Um9jyN0uq+oQuOspxY3RnpKkJ3QmwZXW2rvILaBBQKFyacx3tjg84x2gizqA1lEkaL+Sm/ZNVq7izlN3v2V/CWuKlE4qNdtZ1wP3zL21p2PlVg5yDgHS82QMkRnpQC67yqHchkcL7SqGD5zbibrXWvBev6hLw0+mycWAd2n2turlfdE9wVCv+bdqfzfIKZz+CHAG3TPkBh3eEHcr1f5GBAau8ujtSC2mJfXrCmaO1JaiY3jppBHt20maNl0hKJ4yPDqPB6M0B7RjM9OEgnWTKugP3kK4rHvtkfIIeLuwtw71kmW/J2j53p10Ym9PdtlEOhIqY5w3p7JbVElXBV41nRKjI+RW2elWX8MjwEjyh8hBz90U1r/Sr91lKZSFJHKkUdZY1/VVP8rQRJmk32tAnsiQ4t9qqjWidAAXBz2B5LKacwfQVpISD71uEbtE3RNCVZAYBe778NgpOmDk8xV990rS6C+BSPjXDOvZbFtLrgY1KfvtPeNMXayPqfozJK/4V/R7Waw0RvdY1HyzEXvwW1031A+WMSNkCfcKh125VTY65BCz9z7ulw2zDC5bbW1eHWOMF2X2kpBkSdNSBYfupoixLBIU3rLaU34HqXKb+488ExsZKa7sH0ZAHPtUN/HBRLkrPiY+r8SsbAhqoz+kqzZKBANaFNJ7hFW7f78e4Yrqb3VJIN5Ij6NAsL6V0DYItqd7T0ZbbrhhsNpXWT58ZXFUndo6z7VmRJXBe56qsJYBSPGSpUmHh2tQOz+0/xXQjZtEz0rxuJArSGiNkeUsAGV/fLR/8nV8XOb+EYegLLU/JBCnf7HC1fVWjRoSkVgS8BT2tEUUuL0 Q/P4S57G 25VqMcxxWuUwI49EFuA0y0kD6+mUIcFJEacJlAISXzUN7hww= 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 Fri, May 19 2023 at 19:49, Baoquan He wrote: > On 05/19/23 at 01:22pm, Thomas Gleixner wrote: >> > >> > When vb_free() is invoked, it could cause three kinds of vmap_block as >> > below. Your code works well for the 2nd case, for the 1st one, it may be >> > not. And the 2nd one is the stuff that we reclaim and put into purge >> > list in purge_fragmented_blocks_allcpus(). >> > >> > 1) >> > |-----|------------|-----------|-------| >> > |dirty|still mapped| dirty | free | >> > >> > 2) >> > |------------------------------|-------| >> > | dirty | free | >> >> >> You sure? The first one is put into the purge list too. > > No way. You don't copy the essential code here. The key line is > calculation of vb->dirty. ->dirty_min and ->dirty_max only provides a > loose vlaue for calculating the flush range. Counting more or less page > of ->dirty_min or ->dirty_max won't impact much, just make flush do > some menningless operation. While counting ->dirty wrong will cause > serious problem. If you put case 1 into purge list, freeing it later > will fail because you can't find it in vmap_area_root tree. Please check > vfree() and remove_vm_area(). I misread your mail. My point was soleley about the ranges which get flushed via unmap_aliases() before the block is completely freed, i.e. ->free = 0 and ->dirty = VMAP_BBMAP_BITS. Thanks, tglx