From patchwork Wed Nov 10 08:29:50 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 12611561 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 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 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.com/ This patch used a more aggresive (but IMHO cleaner and correct..) approach by removing that trick to skip swap entries, then we handle swap entries always. 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_detail pointer specified. I found that it's probably broken because of the introduction of page migration 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 shmem, while we should. I'm afraid we'll have RSS accounting wrong for those shmem 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 after 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 affected), but if anyone worries about specific workload that may be affected by this 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 kindly 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(-)