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 243C4C25B7C for ; Wed, 22 May 2024 22:56:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E6376B0089; Wed, 22 May 2024 18:56:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66E1F6B008A; Wed, 22 May 2024 18:56:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50E9E6B008C; Wed, 22 May 2024 18:56:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 23D6D6B0089 for ; Wed, 22 May 2024 18:56:51 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A90921C1B54 for ; Wed, 22 May 2024 22:56:50 +0000 (UTC) X-FDA: 82147543380.22.4CA1C97 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 996D840010 for ; Wed, 22 May 2024 22:56:47 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kIbM1Rko; spf=pass (imf07.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=1716418608; 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=26DyhWPtAiwa8tcvGeS+RsO4MHzBcZzk4dVZxCqXjVg=; b=4tRMs4GP1B1Jj1h1IMZeJNxy4n8ek31ibzGMyO3/zQ/GXSIGXyukeb7U+ovOkKtzP25e1b 0iMQKYrfEzGgM8gfLLtZCQ5STY0nwt+MtgulfTM+DC9OSTEtEsD/pxVUkXsJoSd8Lsmx+M q90p9/6s05QPFKa8Tj2Ie8d3q1qwAX0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kIbM1Rko; spf=pass (imf07.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716418608; a=rsa-sha256; cv=none; b=dTfpofv22RZRMZ3Lqzhg8Xk5OXJBEedtIHC6JtvdoU46I2U6ocJrMJ4Nd8e5GDb5qKkL6D SuK78zlgGNexdwbFDzUj5tWIcRJ9JNuAbjo3RA/GKXdNG7Gsc0vhcYdm7a1oDXsTHBc8NW m0R6FMfRqUcjaALZ5JVG/nNnq/fBZ2M= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 4F133CE126F; Wed, 22 May 2024 22:56:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0113EC2BBFC; Wed, 22 May 2024 22:56:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1716418602; bh=5AT5vl3T88JpLt0rz9YSRvOvlMXsZmaBQLa/LMKnRcQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kIbM1RkovF/daLUCUG4Lj5ojXFRKBEbLrYsAdEO0AYnDNiQOPsIuooTetl8mDXbWy DWUbNJyH4fhaF+XiZnVzeyEroIuUf3apLFR64UlpMNAHUUZpatLMc5RD11DIJM4xy9 st7Ex5hKhDVytxeZoakQYr7EkqEjFGoBAqp0PbEY= Date: Wed, 22 May 2024 15:56:41 -0700 From: Andrew Morton To: Byungchul Park Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, ying.huang@intel.com, vernhao@tencent.com, mgorman@techsingularity.net, hughd@google.com, willy@infradead.org, david@redhat.com, peterz@infradead.org, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, rjgolo@gmail.com Subject: Re: [RESEND PATCH v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Message-Id: <20240522155641.a726c5cd3b25aa23e861045d@linux-foundation.org> In-Reply-To: <20240520021734.21527-1-byungchul@sk.com> References: <20240520021734.21527-1-byungchul@sk.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-Stat-Signature: 49t7js3rhm63ko7h4cudfbrf61jfqj7i X-Rspamd-Queue-Id: 996D840010 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1716418607-804920 X-HE-Meta: U2FsdGVkX19tHSfb5dlgPPfluH7NjuBhYXMD+TMAXQgBEyqOnrpBA1vgOa4bQwmWbcKZOUtSKnb5t7y2flG9iopMfYMFKG1g4Nd4ZQQcnZfG1cCnk3IPU7PJxWaB8GtZNzvlk52SCUFVRNAbMRfL+oIQdjRgoNkdDoGMMfSd+xJGTpQj9B81wivYYjgWSRM7VEoU/A5WubdYV/j43iMAruDUxtq0HKTAXUKplFx3kiHHjSuWKDwcUbqVJRqHPVeTd4fP56pIaxL1ERi1Vqf/HrtNhy+rMg2l0Gmtd7ZpzxPkYXxcM5o0Rl6nXQ94YqO+D3UxQlipnRzvu51h46SZ5sqfevEKV3aKEAL3OhKCQ9PAvg1w3dIDDc/O0fHNw0ZTSu16baFTgJqnOB+rIwCBE2tkLYXl0lJnuc3UUiq3FYnYxGUM/nY32tovXR1FXz9hqD09iDopgSWfMyqdCGDNv1pFRJERYP9Kq+efmbQXPhqQd17pMmO2eYyKXm6RgZ5Chga37LQ21WafC7RZyHgijXzoZdEXf/wylH7eodUtS9EM1GbAQqui9nNp4ovwZ9slWFu/NMQZPPViGV6zQEQR3prrg5tTiyS93qP0f9cFfvRehC/k3Y1N+FdH3zk79T+kAa+sRu5Gu3y46QpnB9AL/H/Avwmiwlco74DLWRjJU1NEnJ3JcTURWKAJDIWxgralcBLyjsgGxKIhtdJ4SZuNwFN4NrcBYEN+8WZtlqdx0TbTdzfP4kXfcMUODYkxLcuZvjvRlI+l5wV6z2RnKKl4R/3R7pCKpgc+3FGtehqfN+ErNQd8U/TrEeQKBCecna4eNG9P+gWZdWt5Exd/stCENWJCYSf23bwri0QHNRlOrrKk0td1Jwa4ruqcvhjjNOAWnr34Pzee8jYpwxKaKhKR+NK9STEV6i2v/10rBnjGkCS5HV+ggHYZW93yaOQ+CUXzeQ2ttLzpijVEysshYJH H+NA7Qg/ oPjdoUk3D/v4VCVy1T+LaAe+tnugGvA4RrpGKpsWckGcY1g3+A3oYPYJkWmVkPHHen22/0F3RNlifQ60CSrCCU47Zdj4kGR1xXtSmt63ULvSktzGwlmf48vG+8VeoZhRC+7gDhT3MGvw7QIHZuDy1uvcGOR/JD32Ho4YvizaC7jBU6h9CKG+V35HB8pHdJxpqx9NSrmXntfF1Ze7lsclpxkRlYjoZDVUM49NHi1RniH9KopggV6wqBkMhNXln39QpZjCeXQItpHJt3dInypns7dHI7owRSVKMFjJdKkzMom9YsAgG1bpj6G6Tq1wzSWzRN9B7kKni7HXVqqCP/6SV4BefAO5y2fGqCjt3ZdUQgVF+elaUrVemT+WzCg== 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 Mon, 20 May 2024 11:17:22 +0900 Byungchul Park wrote: > While I'm working with a tiered memory system e.g. CXL memory, I have > been facing migration overhead esp. tlb shootdown on promotion or > demotion between different tiers. Yeah.. most tlb shootdowns on > migration through hinting fault can be avoided thanks to Huang Ying's > work, commit 4d4b6d66db ("mm,unmap: avoid flushing tlb in batch if PTE > is inaccessible"). See the following link for more information: > > https://lore.kernel.org/lkml/20231115025755.GA29979@system.software.com/ > > However, it's only for migration through hinting fault. I thought it'd > be much better if we have a general mechanism to reduce all the tlb > numbers that we can apply to any unmap code, that we normally believe > tlb flush should be followed. > > I'm suggesting a new mechanism, LUF(Lazy Unmap Flush), defers tlb flush > until folios that have been unmapped and freed, eventually get allocated > again. It's safe for folios that had been mapped read-only and were > unmapped, since the contents of the folios don't change while staying in > pcp or buddy so we can still read the data through the stale tlb entries. Version 10 and no reviewed-by's or acked-by's. Reviewing the review history isn't helped by the change in the naming of the patch series. Seems that you're measuring a ~5% overall speedup in a realistic workload? That's nice. I'll defer this for a week or so to see what reviewers have to say. If "nothing", please poke me and I guess I'll merge it up to see what happens ;)