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 2A1D1C7EE26 for ; Tue, 23 May 2023 15:27:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A05C56B0074; Tue, 23 May 2023 11:27:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B5AF6B0075; Tue, 23 May 2023 11:27:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A489900002; Tue, 23 May 2023 11:27:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7B34A6B0074 for ; Tue, 23 May 2023 11:27:23 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 40647ADE4C for ; Tue, 23 May 2023 15:27:23 +0000 (UTC) X-FDA: 80821898766.21.32155DF Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf06.hostedemail.com (Postfix) with ESMTP id 712F318001B for ; Tue, 23 May 2023 15:27:21 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=none (imf06.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684855641; 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; bh=553bc1V4189A1Tz8eqrT+HGMrBgZSmKgmEL8KV2XCw4=; b=vxgeqDAJVuTkl+2S7Qrl+2mj025Y8uaASaFm/YdeHUp0+327ghX41SM/lHFgCRYPv2x/VQ LQDuwD1URYNoZ8ajX3Hy1lCe/KHdzzb+O06Dbm5VTY9HHNGjIEd+UfjaybkQmyO8AEXhZn SHkn+PJVJmjTB4886fNsC08myNFrmnk= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=none (imf06.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684855641; a=rsa-sha256; cv=none; b=I4sfdhwVZN+LOG6OEM1PlSeV5qCtuN1H710nfZ66T0jyAZxsKdKT/ZMsY2w7VIEpenL1Ef LTy6dPkMpsRWbK6Ax+oopsgNwoI2OWwc5eC+xEjibTSn9gn8ivR09wfXDNKCoC43tcDn3B nlFYmdCIniSF+yi0Piag1XPswTRER0k= Received: by verein.lst.de (Postfix, from userid 2407) id 810DB6732D; Tue, 23 May 2023 17:27:17 +0200 (CEST) Date: Tue, 23 May 2023 17:27:17 +0200 From: Christoph Hellwig To: Thomas Gleixner Cc: linux-mm@kvack.org, Andrew Morton , Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , Baoquan He Subject: Re: [patch 3/6] mm/vmalloc: Prevent flushing dirty space over and over Message-ID: <20230523152717.GC12341@lst.de> References: <20230523135902.517032811@linutronix.de> <20230523140002.690874212@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230523140002.690874212@linutronix.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 712F318001B X-Stat-Signature: najcwiewymof184u4wi9bd6eu56mohp7 X-HE-Tag: 1684855641-852275 X-HE-Meta: U2FsdGVkX18tlxZRRrQqu6ORwFLbIxP6ecax6Rjy/SJzlUa8z2HMHrpvzT17SojRodPcwnFMuZod/qf+kqA3IUBMquQBb0dRX/JL/BDNYt+L92BbG+jYowdKzGWt9B7GnEiTEo1JcVD8DmW2srVDCgHTYLeIsoUy7a76Lm5xRW2YmiWtChUE2jtZrs5rUMxn4Kb+lubw2MKN+O4poxEhWnOn8syZICYbMUrur1xNnZw8WBi3Z6KR8kEcl9vMH1jRmFtJB9gi2L9Am8ePOkE+zec2jNJGgcIsPbXXoznMZg4Lo/VOnOFGF0bMIRPwDh6YDehd6Axk30hPoLrvUFriSffXf+x9+3FCZJ/drgYXKJwvgatr2tCJ+3RLCo6pesVA5qHK6xZvJ0BnUn5yLaK9RXrGUGioYVzGqFzzbyFRL1VkWH4Olr16MZq1fhb+wHHhSn8R+cI1T00Q5MkBJkXMN6ywL0Xy8ceUifKUXtDk41Xs/cdWUDMfKTUJdSwVHsU8ZjeEG3gy0NVLvRCix0DW3i2qPK5gjqh+Nn+kmiTvugzi6hWCU+tzf5GKzS3atRv8qNb+r/pzobEG0VfY3MfrkBZ8jkU1hDcjkiZO+jjI+9oSQ+mxuSKq3ClhyrXmeATRAJ74vnzbWRsGXGfL67kpijl/D28ySL0h1boRhKZ82PYijTs2h3M7kB8bVMFeZjjmq5cNSBk02p6yyh62/12ZpJ1XRVPRBlAFtTSutGR0kMVWTpfl0QsxxzGL7SQjcN8MtFsgvY0GVEOGjU8nIwCQf2d3iWVjMsICyl+tIB1YieiDSMV5AweAnh7oSghFk31ZP1cSUSWZ7b9ipfwe7ZbAxMQTCTS6CCtL00xH1CePrKQCltjz56ydSjRiaP8moH5vzxR+j+1fmdxPCJ/r3eRc+pxVk8DsjvAeTVjGtUrnRZOVJd8SmVNf92WzmSq/aNzK8XIx0lilcFaWqogTcqL bPXhMgjv eMVGtd7CaaMdSwCRyAa7DnWijA26thJYQ7R270KOzFrL2JPm9RwXk1zSqC8uzCqMMUkxAyRbzvAXfo9F0HhapUEOmCQu6DhtCy4rv 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 23, 2023 at 04:02:13PM +0200, Thomas Gleixner wrote: > vmap blocks which have active mappings cannot be purged. Allocations which > have been freed are accounted for in vmap_block::dirty_min/max, so that > they can be detected in _vm_unmap_aliases() as potentially stale TLBs. > > If there are several invocations of _vm_unmap_aliases() then each of them > will flush the dirty range. That's pointless and just increases the > probability of full TLB flushes. > > Avoid that by resetting the flush range after accounting for it. That's > safe versus other invocations of _vm_unmap_aliases() because this is all > serialized with vmap_purge_lock. Just nitpicking, but isn't vb->lock the actually relevant lock here? vmap_purge_lock is only taken after the loop.