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 38B5AC77B7A for ; Tue, 16 May 2023 14:39:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0AF790000A; Tue, 16 May 2023 10:39:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB9FC900002; Tue, 16 May 2023 10:39:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A826990000A; Tue, 16 May 2023 10:39:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 96549900002 for ; Tue, 16 May 2023 10:39:04 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 017F280306 for ; Tue, 16 May 2023 14:39:03 +0000 (UTC) X-FDA: 80796375408.21.2670781 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 0873F4000D for ; Tue, 16 May 2023 14:39:00 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=toWbGUFw; dkim=pass header.d=linutronix.de header.s=2020e header.b=CUs8QWKg; spf=pass (imf07.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684247941; 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=H+s4L31no8WNf+7iGWHjMBGPbaqtRjAg6FlaaNkpyl4=; b=NMy3IMUhjyUbmNuyK+MjzLYLtF8kuug/NGpO2bc7cfg2hefmo1ijYaWTfWso8SYM/0ShYW vpt8KWalmGxMlX/TcgW4NxPluiDZtr2ROjQOnGcY7AEqUABEg/M5pQ/PctEFaqvHEgEDuF xvic50cVXakIFilaSEhmDy5mD9N8IsU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684247941; a=rsa-sha256; cv=none; b=MuITcHN+vo0LCdkTOm2Kb3QnLi95iTuNRms0Xl2h1M5Zc5w11kH+HU5mcw2J1CZ4Pj/Z9v MIDTAKAwyxZKggYaU2rLnCYHixNoJQVSMCXnOW/h1uo8n8EWzhSztrK4tOoAyp8Tfc9TRP Yh3gnqJWZoq54lPM1IH9B7OmodGx+lw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=toWbGUFw; dkim=pass header.d=linutronix.de header.s=2020e header.b=CUs8QWKg; spf=pass (imf07.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684247939; 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=H+s4L31no8WNf+7iGWHjMBGPbaqtRjAg6FlaaNkpyl4=; b=toWbGUFweo5iqHaVmOtwmnjkNOg7140331MwncCz0l4l+C/bdxBy3brnNdFoM+5rEI/dHu kO2M6dnZLM4P/offtRftLnlXblxCJXtXDSYS3q4XZkSVP3l4L8BbdXylSnE90oAmiKYX8J 8M2eh0FbQ8CuY9W3v7vCpv5sSKPppSprQZBb+FE1KrNwu0bCmJfQNxOYJ8zsMoaGSNYnJt dL3m/wGs6UYXZNPXrTQWONLMdmKHV6g9UjZ09suSNcX43eGfVv+AeL6zz9rNurwiPDrlbg Bsig6Mi6tH5nbGYLoFOcN+vKWnQNCMyfhPmgBsdW39dC6YWm6Q+384yEkjSuIA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684247939; 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=H+s4L31no8WNf+7iGWHjMBGPbaqtRjAg6FlaaNkpyl4=; b=CUs8QWKgDH4pbXSoNYBYIG8gFa9dR0xc123eajymPTA2A5GfDu3AwWO4EE0wNXkl3X408c +owl8kSLb3EeQwAw== To: Uladzislau Rezki Cc: "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , 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: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> Date: Tue, 16 May 2023 16:38:58 +0200 Message-ID: <87o7mk733x.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: dudmxxkb96fxd37jthbdhas11yxqm4hh X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 0873F4000D X-HE-Tag: 1684247940-253539 X-HE-Meta: U2FsdGVkX1/fKNGOAg+8HcWO3ryFlIRLlBwXf8KFj/8+Ai+oDr+wXqzvbxtPF7JDh4snFv6D6O5uECVmYyVLaRWLI2WOulJEOgSu4tBkvAILYob+P2rHEDzp2qKNOEdXAdqycij2Z6zjmhqNxYdB6VE8iAtYMJtbwCeElQc+YQ/bpxxsBGuS9s5XSpYTO5PJdfYXizMJsYbxRA182FsAY2nb8HE2N938+9TBeW6vNO3e+6QkIvl2NQ/FLR7giNVzBO87mqkg94DdtY0H5ZXd883nFnT3w4Poh7xXF7nrx2YT0hsjq4ROifmO7PbJqdjq38Y7X+/+ollLwzZvaS6GUXNdBpFkZW1JHjhnFByDps2EWrbiSBhArPmh8i06AcM5kR3X5ztjaI/HFcqg3iH6aba8Yzg8lFXWWzYdsGXDWf8w9sc2som+V5/35qtMAZjQC8PjYoUBsKVPUmeALpTJiGEHEdi9/ainXZdDPnyU/Vu7X5De5xQMOaLMZ2dVC0D1mCQ5kJQ/VE5V7DqC5pw58teJO2rG3hggDbCk6ROtKBASB6jkCo7YT347+jvFAoIlRk2ShlZHvdzNqghjKJZ+KTeEOHR5G2tJMPsRbye60jAxQTz6tirHbeU3J29mqgT+SN5Iw03jnN/NGSbAltVI4xlqhaDpg8YhQ8JjERs4o9tXefu8c81uKvld9j0ZmXTjdQnrGZwtwr1J7knIS/eqbNPADU9BVOTB123MuDerSdpTsjhJruYy3+hDGFrnwzNg5ZAn9jNVl0+0UmdhR/ugtHbKMc+wGd5XU2rIeuE4zeHC30wqsPuQX5BlnwTux7iA1DFxEfJBXLTl0tT6DuEHQFKtlJXSh2/8GZgySv2qlYcXQhrxKD6OwGatnf1W9JZbkBkvf7mfPHZgvJCsGV9SkZDVgKTyVOd0hZ6wxIJCK8JKZtgCwzCOQtVknyL3aZLo1J7vUCmxIqLH+L8ln7F ixUXFYME Q+mmo4nMpia9WzzHs3afV1FepsYrGrVo3paSKxnFYPnq+AVY= 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 Tue, May 16 2023 at 15:42, Uladzislau Rezki wrote: >> _vm_unmap_aliases() collects dirty ranges from per cpu vmap_block_queue >> (what ever that is) and hands a start..end range to >> __purge_vmap_area_lazy(). >> >> As I pointed out already, this can also end up being an excessive range >> because there is no guarantee that those individual collected ranges are >> consecutive. Though I have no idea how to cure that right now. >> >> AFAICT this was done to spare flush IPIs, but the mm folks should be >> able to explain that properly. >> > This is done to prevent generating IPIs. That is why the whole range is > calculated once and a flush occurs only once for all lazily registered VAs. Sure, but you pretty much enforced flush_tlb_all() by doing that, which is not even close to correct. This range calculation is only correct when the resulting coalesced range is consecutive, but if the resulting coalesced range is huge with large holes and only a few pages to flush, then it's actively wrong. The architecture has zero chance to decide whether it wants to flush single entries or all in one go. There is a world outside of x86, but even on x86 it's borderline silly to take the whole TLB out when you can flush 3 TLB entries one by one with exactly the same number of IPIs, i.e. _one_. No? Thanks, tglx