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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88D18C433EF for ; Wed, 10 Nov 2021 08:30:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32190610A3 for ; Wed, 10 Nov 2021 08:30:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 32190610A3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C45F86B006C; Wed, 10 Nov 2021 03:30:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BCE806B0071; Wed, 10 Nov 2021 03:30:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A485F6B0072; Wed, 10 Nov 2021 03:30:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 930DE6B006C for ; Wed, 10 Nov 2021 03:30:05 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3339A7CA2F for ; Wed, 10 Nov 2021 08:30:05 +0000 (UTC) X-FDA: 78792347928.26.C3EC9FD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id BFC0130000BC for ; Wed, 10 Nov 2021 08:29:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636533004; 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: content-transfer-encoding:content-transfer-encoding; bh=ZFcWdRsz7OaakLNSt9pmiFaVGZ1WxUx5Us6fbMaYsT8=; b=B8AEhfi/oDYnTFDt2Zs4/cGbHoj20wQpY1H63iS524d2F3ds8KbslLXlm+sLxnJbzchojM lkNJzsmduI84+LDLt8glEOAPbGKtV0lX88rKlB3bKilsMfMjIzq0EtSS74bEqP1O9/2wIV C1WtEnI7sX9rofoobpVk2JUl9qmsRv4= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-lZeY59V2Poq-slOvJ72zWQ-1; Wed, 10 Nov 2021 03:30:03 -0500 X-MC-Unique: lZeY59V2Poq-slOvJ72zWQ-1 Received: by mail-pj1-f72.google.com with SMTP id iq9-20020a17090afb4900b001a54412feb0so661798pjb.1 for ; Wed, 10 Nov 2021 00:30:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ZFcWdRsz7OaakLNSt9pmiFaVGZ1WxUx5Us6fbMaYsT8=; b=BWvxjYOc2LofJAHlJ+Lg3r841xD/UYVYk/zXc+2H34JCUn+GSGQ3yeQFpiHjcsi8JG liDs2eoUJXDCCqYdfs8ofIORkxH9uQKA53o1mP4a0Kf21re4UGq7m3TizERcCMEECppu vz8dm5GqlTYdB6VhmHjkchVy61RlRzDPaJmldENYwLX7jBcKPMAIjzFTZs4VGeqH2Ybh 6mw4pUW3bp8pGgaPpayPUMlvJHNHrA8rOmQgVojeHx5Dx+bzJOI/VWoJJ55P4p/hTxJY HHVtmMgSYACSmzSmNXUzDg9/8cbE9FSWeibf4TpnoBGG8OJ0WrH2nHBydnkA3vQ61ZHG yfbw== X-Gm-Message-State: AOAM533A6kTVJ9Dhx6Ke+kRSkECnKCk8uQwfsE7vdfKZJEM0ueOcca3G iUW1PiB4AddRmf3x/IESsfBinWnGpEKzSlUyB4fW2yxGprJb0aaK2LHQi3lZT91Y8Ff395X2pl2 5vTYYdLpClZQ= X-Received: by 2002:a17:902:a50f:b0:143:7dec:567 with SMTP id s15-20020a170902a50f00b001437dec0567mr5309236plq.18.1636533001760; Wed, 10 Nov 2021 00:30:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwEERck+ZH1HW6dD3qoJ6BXiElxaGglbRCS3RSwZktnCqTK+ZBWrGu2dU61vN+ChCkGIUOkGw== X-Received: by 2002:a17:902:a50f:b0:143:7dec:567 with SMTP id s15-20020a170902a50f00b001437dec0567mr5309214plq.18.1636533001499; Wed, 10 Nov 2021 00:30:01 -0800 (PST) Received: from localhost.localdomain ([94.177.118.35]) by smtp.gmail.com with ESMTPSA id s7sm23709986pfu.139.2021.11.10.00.29.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Nov 2021 00:30:00 -0800 (PST) From: Peter Xu To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: peterx@redhat.com, Andrew Morton , Yang Shi , Hugh Dickins , David Hildenbrand , Alistair Popple , Andrea Arcangeli , Vlastimil Babka , "Kirill A . Shutemov" Subject: [PATCH RFC 0/2] mm: Rework zap ptes on swap entries Date: Wed, 10 Nov 2021 16:29:50 +0800 Message-Id: <20211110082952.19266-1-peterx@redhat.com> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BFC0130000BC X-Stat-Signature: hye43kb36y9thnn7qzkasxaksswubc93 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="B8AEhfi/"; spf=none (imf08.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1636532990-338551 Content-Transfer-Encoding: quoted-printable 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: The goal of this small series is to replace the previous patch (which is = the 5th patch of the series): https://lore.kernel.org/linux-mm/20210908163628.215052-1-peterx@redhat.co= m/ This patch used a more aggresive (but IMHO cleaner and correct..) approac= h by removing that trick to skip swap entries, then we handle swap entries alw= ays. The behavior of "skipping swap entries" existed starting from the initial= git commit that we'll try to skip swap entries when zapping ptes if zap_detai= l pointer specified. I found that it's probably broken because of the introduction of page mig= ration mechanism that does not exist yet in the world of 1st git commit, then we= could errornously skip scanning the swap entries for file-backed memory, like s= hmem, while we should. I'm afraid we'll have RSS accounting wrong for those sh= mem pages during migration so there could have leftover SHMEM RSS accounts. Patch 1 did that removal of the trick, details in the commit message. Patch 2 is a further cleanup for zap pte swap handling that can be done a= fter patch 1, in which there's no functional change intended. The change should be on the slow path for zapping swap entries (e.g., we = handle none/present ptes in early code path always, so they're totally not affec= ted), but if anyone worries about specific workload that may be affected by thi= s patchset, please let me know and I'll be happy to run some more tests. I= could also overlook something that was buried in history, in that case please k= indly point that out. Marking the patchset RFC for this. Smoke tested only. Please review, thanks. Peter Xu (2): mm: Don't skip swap entry even if zap_details specified mm: Rework swap handling of zap_pte_range mm/memory.c | 31 ++++++++++--------------------- 1 file changed, 10 insertions(+), 21 deletions(-) --=20 2.32.0