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 9603ACF9C6B for ; Tue, 24 Sep 2024 21:31:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6C8D6B00A7; Tue, 24 Sep 2024 17:31:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1C7A6B00AA; Tue, 24 Sep 2024 17:31:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBCFC6B00AB; Tue, 24 Sep 2024 17:31:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id ADD8B6B00A7 for ; Tue, 24 Sep 2024 17:31:02 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 28F3DC03D5 for ; Tue, 24 Sep 2024 21:31:02 +0000 (UTC) X-FDA: 82600927164.06.906A808 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf26.hostedemail.com (Postfix) with ESMTP id 53070140003 for ; Tue, 24 Sep 2024 21:31:00 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WPKVpUGo; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727213340; 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=UK3FQYwyep1LbEvPzyg9rqOUpH5U4QQ1vXKngoT9gv0=; b=8EXwKosvT+ZIBy0nnGsnep344VtjPYFCzYSPnKIptHtEuW2BbOzFH/mhtqNAQB/zPx45ow H03AHaodDulQ7pg0guWbgMFLs3m7JlIDhyYo1gJc7qbwUhpWgCtPyEi2BSeYth+R4phPrX fyPILDfUuL6onJR9iAmFEqEFKTap3Tw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727213340; a=rsa-sha256; cv=none; b=mGgCLa2+RE049u03Ak0VLUuSCWVDhqSPbVxDI8yP/PcQrVAN0e1wyY+xXfXOHdMh+dwTGt 3E5ClyqXhLMFvXWwq8Wy9gqqCSKQ84I0siUmmZpOJOCB5xUbb5QCSJHDJNPDl4Nhkk2JAS QoLxN4S2OoO+dTJNn3V6ptpwg5zwSuo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WPKVpUGo; spf=pass (imf26.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a8a6d1766a7so845758866b.3 for ; Tue, 24 Sep 2024 14:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727213458; x=1727818258; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UK3FQYwyep1LbEvPzyg9rqOUpH5U4QQ1vXKngoT9gv0=; b=WPKVpUGoL85OjVFp4lX51cJ1scVi/CIZsIpj8RIFaQk1tJqAdGn1SF7OdsS1JJG0gN L898u95EW57NTMiTx+n93QoYe5csWJ+cOU+6znBvebg1+sN28RWVRR3fX/852ee8PkTV cTqhO+e6pp0Ju6iavu5hZAUv/t4ASVdKCiGttwrE3Pa0+8sGgfpoIgR2XByq2K6I/LhC xyGT45O25i3iOflUU/mEYGJaT25OMi2u/93TzrnxG4VXgJlYeMpAXcs1L5mhYZZTyvs6 L/lze4r9Gs+SJpngn44ffe+i2/AvqX6qGqoXFmrjB7O1oeZd+IsUCF3reotLUvee65VE deTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727213458; x=1727818258; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UK3FQYwyep1LbEvPzyg9rqOUpH5U4QQ1vXKngoT9gv0=; b=gCS2hugM25ZhOMbLCYVyeHjzn8xHTN1O2aWzHpk4OXaCYbk14rHxqH1+FLgFzMqmE1 YY5VRJ5lR4yt2jm4JP+syR2Z5tG1ucz36AeOtavFliM37veL3lEhRW7Q2rxDhYKjevNn rut9+Oz4H2mCX8jQEeXOkKtgaVnUV/iBGniSIFWplnd5PSTWJsqbIi9vpeKoYZRJm8iN xTp1m3CjnQvRBZIZNvZeJbNOKMuPFBBgK33pckxRG5O5Gh7KmHjKQJL8AD9AHOTtPLIN 44ILHyWrHhFn82dJBBXgpsKhF0T83ECkaLhInulaWNKNgcyvxxCok/3N6rn5JEMc/Rh+ sDAw== X-Forwarded-Encrypted: i=1; AJvYcCX5KCq/NGlptAiWActbxPlTAu2mjiDEd8BGcx+jvDucuUbMOiAQcO1xOomXXDt9zEbEraV2Rf9+rA==@kvack.org X-Gm-Message-State: AOJu0Yyn/w4JWVC3/tHDkYHBquYkVy+N9CvR5EZ/rckEttP7iWEpWfz/ IZg3z9HuHOjjCjEBCmifQ6cm16Tg1vbnOk5NzXbKYNh12KOKGpARUUp+uRT8n0gIlnFdMsocceu hSziHeF2qsGHUXQ9yEBI4o6pHbQFe4TZQB0cV X-Google-Smtp-Source: AGHT+IGkAGFefNv9T8DJPD71R6ZGJ7RNDS6uicSXaTq/T0ESxfN682KR98fwDB1GyCr24aT82UTh1lnu3J4nP/TE11o= X-Received: by 2002:a17:907:948f:b0:a8d:75ab:17ca with SMTP id a640c23a62f3a-a93a03f49femr46462966b.31.1727213458244; Tue, 24 Sep 2024 14:30:58 -0700 (PDT) MIME-Version: 1.0 References: <20240923231142.4155415-1-nphamcs@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 24 Sep 2024 14:30:20 -0700 Message-ID: Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM To: Chris Li Cc: Nhat Pham , akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, ying.huang@intel.com, david@redhat.com, kasong@tencent.com, willy@infradead.org, viro@zeniv.linux.org.uk, baohua@kernel.org, chengming.zhou@linux.dev, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: fim9inhqbnafxj8rajywi45gbib543zr X-Rspamd-Queue-Id: 53070140003 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1727213460-175389 X-HE-Meta: U2FsdGVkX18WbLgJAuZNkYnaFTnLB2szHVOJZSWW47wJpQOs/P5fd8dn6Nzuvr3IgnmGoVF4tbLYJxnUoB+WRmRl7HcwQQIZ8lH7Vy0tRzKQ+g1Oww8gpsouGVHn5h9DBjF8g/o2N11wKRnNR32Cehofbvs14rVjIZGW9h+EYtIGpOLG8rbOOa7QTsfT3xf2J11uWdsOz5viApPIYi9BGDpFtOGT88t9UDT9qx9hTlMMCiQTkL7f/LNBcqYNEsXK+CrqlHOYMZn37PeFj6fHIeYe2jMDEjK1sFQAts1B4RMSgmP3yD1cUWVSbfyvWlkd+/w5hvSejnftE8AWJ5e2klL8BJWyeQrbJj7juymO8GdhiKDAfqR1rV3jnVfdGpczj+Mm4gAHbltCLmSUNQTKU82uFGRbjCCbaADboXo0e0usgcOuiDCKIiZibAIAHMrv+iAAbpCTyJUitxXyBJVDTtLQrowkdp+VLcZJkUqd6WNkp+G1zUQc/SEO07ZeY77rlL96blPt5XP2H/aEGzhd1Y6bkhjw5Wfqo+j7Sm7gTw4Vp4hD6DGHWmr1VoBVqyHgm7DDP6lolhEq6/r0QqUkaXe+7whL+F3ekshrH1ZtoynmpzR4E1HWmsi3HRxXJdEw/qqeb76KvjlLFZ8FkNKyUp1t8IsDV6QA5zwbqgqU0P26/b5kmco1jqeiQijA/nbKHyusOerEY/W6O3HNvPIunH1p1Ehtcp5YYuDDK+dOEcMvk2SrJHugy//sMHI0dYAHXTJQXnthFqoXIcYtNO8+faSbXBapkwVi2+F548R/u3TTEfr7gjK2XopEsGBwxf/HhmuW1zLaL8to5zSyaeqmRcQjIRQJ4TQ8PWyONe4/k1iqzZEOT55WvFT3GxH2mc5NiaIuQ7G5pS7LwlDh4bk1AFc208iOC5H4zq1McvKpFmOPHCaOAlhb7p9gB0a0dC1cDzVUdhjOfoUUAOXnkJY +7xvEkVe zNFAu/xwU3MmralITWry2jXpG1K17c8ieTfDZHcE0EKCpMwlQ/KLrLsAnepR4o0nky3hKofz24zT2uzRlT9cOxmMerh/S5qt7Zf39Jl1RFYkUVV4nONMUGvqWQCx832rWBVgRWwKAqR4RhGt3NjTUovVsuEBvQRhcvWmS1kArqKcee1UVfgQpplPtcVRzw+Rv2nop4dxwgamWVdlDSQcNa+NmcEi/oSM/IC0kcPF3cQlyBIiFs8Nm7Chrmh+RzHvF2XsWAwAM1xpvTLftUisfXIGga4b4Vz/3IWpH X-Bogosity: Ham, tests=bogofilter, spamicity=0.000918, 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 Tue, Sep 24, 2024 at 1:16=E2=80=AFPM Chris Li wrote: > > Hi Nhat, > > On Mon, Sep 23, 2024 at 4:11=E2=80=AFPM Nhat Pham wro= te: > > > > The SWAP_MAP_SHMEM state was originally introduced in the commit > > aaa468653b4a ("swap_info: note SWAP_MAP_SHMEM"), to quickly determine i= f a > > swap entry belongs to shmem during swapoff. > > > > However, swapoff has since been rewritten drastically in the commit > > b56a2d8af914 ("mm: rid swapoff of quadratic complexity"). Now > > having swap count =3D=3D SWAP_MAP_SHMEM value is basically the same as = having > > swap count =3D=3D 1, and swap_shmem_alloc() behaves analogously to > > swap_duplicate() > > > > This RFC proposes the removal of this state and the associated helper t= o > > simplify the state machine (both mentally and code-wise). We will also > > have an extra state/special value that can be repurposed (for swap entr= ies > > that never gets re-duplicated). > > Please help me understand. After having this patch, the shmem swap > entry will also use the swap continue as the only way to count shmem > swap entries, am I missing something? > > That seems to have some performance hit for the shmem. Because unlike > anonymous memory, The shmem can easily have a very high swap count. > I would expect there to be some performance hit for the high share > swap count usage case. > Do you have any test number on high shared swap count usage that says > it is negligible to remove it? Shmem only calls swap_duplicate() once in shmem_writepage() when we add the swap entry to the page cache. We do not increment the swap count once for each user like anon memory. IOW, the page cache is the only user of the shmem swap entry, so when we remove SWAP_MAP_SHMEM the swap count of shmem pages will either be 0 or 1 (disregarding SWAP_HAS_CACHE). So the swap continuation code is not used here. > > Also if you remove the in the SWAP_MAP_SHMEM, wouldn't you need > remove the counter in the shmem as well. Because the shmem counter is > no longer connected to the swap count any more. Not sure what you mean here. > > Huge, do you have any feedback on this change? Hugh* > > Chris