From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CCFB94A07 for ; Mon, 6 Apr 2026 05:35:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775453751; cv=none; b=d96pJelfNpXnJAG9wVj0PbM06MebDinUIqH7px+axBQL+RzINkE+J51pNEv7mMk6XEn2TfG1Ul+AM1ItrIx3d0Qk/sz6JJMpKU4y21DKSxRgO+pxh2D1MdrSrVRAGrfbqCdQ4txCVlRYPBRdCVasMcl6Civgbm7YAz1OYaUuc58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775453751; c=relaxed/simple; bh=ZyueJH/pHzig3DsgShkAeSPO0/r8VtnpluFW+RqEQUI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=EHrQAHzKSZ0hNZK84KqI5n1iJN7+/PLl5xXLR8gJ/LLUCo+uIKS30U8RiI6n3OzngUcXAKV8QtG/vj65n3ODsgw6xQ1DczuYsON9tiVPd0uHxMWt3XS6KptAKjJokS+QmkRwN6eR93h+mlpy1speLza8WgzUH83nyY88VcU/Joc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=gXB+tNy6; arc=none smtp.client-ip=209.85.128.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gXB+tNy6" Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-79ab5fd969aso33399317b3.0 for ; Sun, 05 Apr 2026 22:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775453749; x=1776058549; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=9FJme28X6M+hpI3k7xxHy5T5VcxdI3tFo8G0ICpt4XA=; b=gXB+tNy6Y4u9bVlJJMHrIL8ikyDvuhzBSCY2v0+IBfo68sCbxN6NuorxM72oXoYocS TKsGLSjGm6F4aWEWbrlw1OmvDfMNwL8+Cg46jYaQUU46GbP+B2vwoIMIsyfANF611utw cerej9NuU9ZBnmO5RABevhIZ7k3cNh6eT5A/eVcCo5jgFCxuacmkjpq+chNunwiLxseD iP3soFvTFr9cCCZ9WRvB1lIppmCsA1waVKtmgxWzH6NAO5vUywD1lREAaPnWOcMW95Bs yVawR8uvYgGL+BVVbmHddRu9gUoFcYyBJGH3kTXb7Ve8rNrcTgSuIOiFCaW9ekdCgi4c 920Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775453749; x=1776058549; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9FJme28X6M+hpI3k7xxHy5T5VcxdI3tFo8G0ICpt4XA=; b=VYxBXlmykmv4+RLOSKn3+KAQ/r7Vlb1CVttGEVI1jjiHZFXrgKN+hwRhIjw6qirBPI kJqrip8ygOFwTz02hfVPFKDDqfvUjvotN99RJTJTqab0PARlIM0DJOz6rN2JlstnVV2f Z2VyTwpLW4xvN69G77nvGYooHIKLfDoKas/sNJV2b3crJTfAZ6NzmZKEAmfTVSHPiGfY 03JKe6gj8zJrEeIF3EShA0cw9zXuCDixBFGlG2okGWzldI4hcNLIJiSn8AWOJCEEALsM n4rzuLEpbgU0kcqi/KKwqQ8SC0jbBTw21SWNh9hnfMpq/qCVw/MTbGiidCQN+jLVoNHE Q4sA== X-Forwarded-Encrypted: i=1; AJvYcCUbTSXUwTPSTU+sm/339xczKAbJbENpXFdWdGKX1HDgzIJX1413qOUzfE0gpmqsC8VSf6wX8S2DSiKIi0M=@vger.kernel.org X-Gm-Message-State: AOJu0YwYlj5BjA4+etmp6xIzLh58UyQCbgFwzPaTkx7x2ljVcxYN3LCq 3O/77MJVrMHzbvIRoG8L7YbjsnFMpYnWQkFPTXdqaQCmOpg3qlyOtLBH9bwnz5bqrA== X-Gm-Gg: AeBDieuggQVDTKOdaIXwW9GoQOsc0/LP5yWnxtAhBe6CmBfQPWQZnnqz7NX9xSmaQhD OPFKXIMP2OAWwzem9wQuAJAOfbasRbCwf9Kmkc2AOHf1IAMivoksxSp1oynbTob++Xy5+nf4R6b p4ASY62ek88PTJqDehgoVZigTzAZHkoBIbJykj696QG03wQenE+QE4c/9RggjJ2YBxH3lVqd9G3 jAdBUff396ACYS64I0a7GjzNSiAfwNtv5jkaPZzAQ40vQfXm/pWdIA1qmGJN699zaxE+EhXErgl wExbU2Dqr0yZl4WUwPBoN6Tx+HQGrsNwmQ60jL2F+uCRQDc3yAU/WEXf+nVLVuNZABlCkL9uxzC hcB/z0+hgrSwmS9Dy41Bz+uFFj0NJyH6WvvahVWH0KYp8WbyZPqH3ZwACNgA5gUeXB0Qt+8Lcw0 IuxdT1oPEMI8aQ+RDOxzg1xMc7Z8UG+h0OGXmZsOcnI1e9lNzFR4FTcUIIbfi9NSri+BnQVrYhP hGBQAY0a08= X-Received: by 2002:a05:690c:e4d6:b0:7a4:db43:c1da with SMTP id 00721157ae682-7a4db43cc17mr88182507b3.0.1775453748466; Sun, 05 Apr 2026 22:35:48 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7a370901513sm49673367b3.29.2026.04.05.22.35.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Apr 2026 22:35:47 -0700 (PDT) Date: Sun, 5 Apr 2026 22:35:35 -0700 (PDT) From: Hugh Dickins To: xu.xin16@zte.com.cn cc: hughd@google.com, akpm@linux-foundation.org, david@kernel.org, chengming.zhou@linux.dev, wang.yaxin@zte.com.cn, yang.yang29@zte.com.cn, michel@lespinasse.org, ljs@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/2] ksm: Optimize rmap_walk_ksm by passing a suitable address range In-Reply-To: <20260406095804589iRP1BCGrNX3DviT29nv2O@zte.com.cn> Message-ID: <9950c6c1-f960-58c0-4312-e4f5ac122043@google.com> References: 20260212192820223O_r2NQzSEPG_C56cs-z4l@zte.com.cn,20260212193045556CbzCX8p9gDu73tQ2nvHEI@zte.com.cn,02e1b8df-d568-8cbb-b8f6-46d5476d9d75@google.com <20260406095804589iRP1BCGrNX3DviT29nv2O@zte.com.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Mon, 6 Apr 2026, xu.xin16@zte.com.cn wrote: > > > > But it's years since I worked on KSM or on anon_vma, so I may be confused > > and my belief wrong. I have tried to test it, and my testcase did appear > > to show 7.0-rc6 successfully swapping out even mremap-moved KSM folios, > > but mm.git failing to do so. > > Thank you very much for providing such detailed historical context. However, > I'm curious about your test case: how did you observe that KSM pages in mm.git > could not be swapped out, while 7.0-rc6 worked fine? > > From the current implementation of mremap, before it succeeds, it always calls > prep_move_vma() -> madvise(MADV_UNMERGEABLE) -> break_ksm(), which splits KSM pages > into regular anonymous pages, which appears to be based on a patch you introduced > over a decade ago, 1ff829957316(ksm: prevent mremap move poisoning). Given this, > KSM pages should already be broken prior to the move, so they wouldn't remain as > mergeable pages after mremap. Could there be a scenario where this breaking mechanism > is bypassed, or am I missing a subtlety in the sequence of operations? I'd completely forgotten that patch by now! But it's dealing with a different issue; and note how it's intentionally leaving MADV_MERGEABLE on the vma itself, just using MADV_UNMERGEABLE (with &dummy) as an interface to CoW the KSM pages at that time, letting them be remerged after. The sequence in my testcase was: boot with mem=1G echo 1 >/sys/kernel/mm/ksm/run base = mmap(NULL, 3*PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); madvise(base, 3*PAGE_SIZE, MADV_MERGEABLE); madvise(base, 3*PAGE_SIZE, MADV_DONTFORK); /* in case system() used */ memset(base, 0x77, 2*PAGE_SIZE); sleep(1); /* I think not required */ mremap(base + PAGE_SIZE, PAGE_SIZE, PAGE_SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, base + 2*PAGE_SIZE); base2 = mmap(NULL, 512K, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0); madvise(base2, 512K, MADV_DONTFORK); /* in case system() used */ memset(base2, 0x77, 512K); print pages_shared pages_sharing /* 1 1 expected, 1 1 seen */ run something to mmap 1G anon, touch all, touch again, exit print pages_shared pages_sharing /* 0 0 expected, 1 1 seen */ exit Those base2 lines were a late addition, to get the test without mremap showing 0 0 instead of 1 1 at the end; just as I had to apply that pte_mkold-without-folio_mark_accessed patch to the kernel's mm/ksm.c. Originally I was checking the testcase's /proc/pid/smaps manually before exit; then found printing pages_shared pages_sharing easier. Hugh