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 E86FAC00140 for ; Tue, 2 Aug 2022 20:35:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CF0C8E0002; Tue, 2 Aug 2022 16:35:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77E148E0001; Tue, 2 Aug 2022 16:35:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61ED38E0002; Tue, 2 Aug 2022 16:35:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 523CE8E0001 for ; Tue, 2 Aug 2022 16:35:39 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1E3A2C0F32 for ; Tue, 2 Aug 2022 20:35:39 +0000 (UTC) X-FDA: 79755808398.30.C1D8F46 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id A3323C0100 for ; Tue, 2 Aug 2022 20:35:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659472538; 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: in-reply-to:in-reply-to:references:references; bh=p3U/5BApyUmmUvsft8lwvJPhjHAwYqDE5trVI8sMuPI=; b=TEAvSPrxeOde0HM/LhQ4ubRIE4WR6yb8ecHLsVMGI1ZX3LFstOlmGcpIZW/HstVL6CZqqB iW1k8DOjRV6sVICik5+8IfzdBaGzDqd6N/t7VQUGpuBwQJ/EJVpI8OplIQNoZp0Jy74gLP JSA8o2+oGTYTpwKqtwfDM0XhnGqeNRA= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-274-BgCOJiryPDyPtVqrpBim8g-1; Tue, 02 Aug 2022 16:35:37 -0400 X-MC-Unique: BgCOJiryPDyPtVqrpBim8g-1 Received: by mail-qk1-f200.google.com with SMTP id s9-20020a05620a254900b006b54dd4d6deso12262525qko.3 for ; Tue, 02 Aug 2022 13:35:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=p3U/5BApyUmmUvsft8lwvJPhjHAwYqDE5trVI8sMuPI=; b=s7JZz+jHTMyxv79YM0BemXp7FAOW8fhPAONcmxSaqVgkGUJOeSa8zsZA9eLBQe3R0W KdacR1lITxMSGD6kDf8xn2uQ7Iv+wpYGMfpNKcjKvHPqCB7Uh8JD7+qzj41RcbzrMtQw hgT251BWAoRrEuSBumRf2ffXQ9Nxq2+eZRC6W06zpC7yVmCvYTwF4XNDaqYN0LxWFBaI 2TiphRLg6MeZD6fwNqo8IV5HkyJILdvAMNI+9aCULIE9l1ZX9Fc45quLkXFfIp2p8qS3 gEHiq4vmaWI+u3FckwxcX1AYRzaJ7GaieGO+F7Wh2EJDhVl2+4+qM+J/+D5UZ4TlIkWU eRIg== X-Gm-Message-State: AJIora8mKX7qpgy+5pXPBija4M9p4sYZd0PLjJGgDXxWWlRgKvycwBhX lgI0XcuV4+t8+pj8eDH2KEHZPqbGi1kGFYQ+j+mRWxqSl29r1p7mNDlacaVSBkManwV33bqQd4d MJKElTQN8Ye4= X-Received: by 2002:a05:622a:1791:b0:31e:f628:f4b4 with SMTP id s17-20020a05622a179100b0031ef628f4b4mr19636422qtk.217.1659472536419; Tue, 02 Aug 2022 13:35:36 -0700 (PDT) X-Google-Smtp-Source: AGRyM1voIR8oG53y0v8V5Ahmi4x98Er+qjWvc3N02EkxNLibhCfZqH4PPMi5/CcPR9k3KbXjjOjecA== X-Received: by 2002:a05:622a:1791:b0:31e:f628:f4b4 with SMTP id s17-20020a05622a179100b0031ef628f4b4mr19636401qtk.217.1659472536195; Tue, 02 Aug 2022 13:35:36 -0700 (PDT) Received: from xz-m1.local (bras-base-aurron9127w-grc-35-70-27-3-10.dsl.bell.ca. [70.27.3.10]) by smtp.gmail.com with ESMTPSA id s6-20020a05620a0bc600b006b5f68bc106sm11130072qki.110.2022.08.02.13.35.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Aug 2022 13:35:35 -0700 (PDT) Date: Tue, 2 Aug 2022 16:35:34 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , Andrea Arcangeli , Andrew Morton , "Kirill A . Shutemov" , Nadav Amit , Hugh Dickins , Vlastimil Babka Subject: Re: [PATCH RFC 0/4] mm: Remember young bit for migration entries Message-ID: References: <20220729014041.21292-1-peterx@redhat.com> <49434bea-3862-1052-2993-8ccad985708b@redhat.com> <24ffea6e-ca66-2b94-c682-48a42a655fd1@redhat.com> MIME-Version: 1.0 In-Reply-To: <24ffea6e-ca66-2b94-c682-48a42a655fd1@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659472538; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=p3U/5BApyUmmUvsft8lwvJPhjHAwYqDE5trVI8sMuPI=; b=XHSFIDd9v5ArU7CG+j28RXvyiee4pPNaKn0cI6a1vM+zy01bmdrht+eX8muNJiTFUILSvh yMphm/S3pqvGOLsxarnsAjhuK9T9JKFdOLHzzXHwyG7ydrnrpKjo/8jXjeS0a80Dk+tDSw s3sdx1TTPzWSpQkEi4p1viViZqTOwhw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TEAvSPrx; spf=pass (imf28.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659472538; a=rsa-sha256; cv=none; b=jN9QucrpMq6o3GxsXctKpgE1mVetzbTvKPuURrttirZk7wXktuPe1gG4TeZxsMsPZv0k6B 2+HUx3pyF01CbZaj+8Z5D+d7IVfveWfc0xfRuA3wTEl++eF4J4l4M7AmDCXgGKc3TzF2ww oU4XTl/M4+1Nado8FEPD84dHRhdPTVc= X-Rspam-User: X-Stat-Signature: r7o673zbc1ymqudz8r8y8856c1j6i6f7 X-Rspamd-Queue-Id: A3323C0100 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TEAvSPrx; spf=pass (imf28.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam08 X-HE-Tag: 1659472538-810898 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: On Tue, Aug 02, 2022 at 10:23:49PM +0200, David Hildenbrand wrote: > > I don't think we only care about x86_64? Should other archs have the same > > issue as long as there's the hardware young bit? > > > > Even without it, it'll affect page reclaim logic too, and that's also not > > x86 only. > > Okay, reading the cover letter and looking at the code my understanding > was that x86-64 is the real focus. > > >> > >>> > >>> Besides I actually have a question on the anon exclusive bit in the swap > >>> pte: since we have that anyway, why we need a specific migration type for > >>> anon exclusive pages? Can it be simply read migration entries with anon > >>> exclusive bit set? > >> > >> Not before all arch support pte_swp_mkexclusive/pte_swp_exclusive/. > >> > >> As pte_swp_mkexclusive/pte_swp_exclusive/ only applies to actual swap > >> PTEs, you could even reuse that bit for migration entries and get at > >> alteast the most relevant 64bit architectures supported easily. > > > > Yes, but I think having two mechanisms for the single problem can confuse > > people. > > > > It would be one bit with two different meanings depending on the swp type. > > > IIUC the swap bit is already defined in major archs anyway, and since anon > > exclusive bit is best-effort (or am I wrong?..), I won't worry too much on > > It kind-of is best effort, but the goal is to have all archs support it. > > ... just like the young bit here? Exactly, so I'm also wondering whether we can move the swp pte anon exclusive bit into swp entry. It just sounds weird to have them defined in two ways. > > > archs outside x86/arm/ppc/s390 on having anon exclusive bit lost during > > migrations, because afaict the whole swap type of ANON_EXCLUSIVE_READ is > > only servicing that very minority.. which seems to be a pity to waste the > > I have a big item on my todo list to support all, but I have different > priorities right now. > > If there is no free bit, simply steal one from the offset ... which is > the same thing your approach would do, just in a different way, no? > > > swp type on all archs even if the archs defined swp pte bits just for anon > > exclusive. > > Why do we care? We walk about one type not one bit. The swap type address space is still limited, I'd say we should save when possible. I believe people caring about swapping care about the limit of swap devices too. If the offset can keep it, I think it's better than the swap type. De-dup either the type or the swap pte bit would be nicer, imho. -- Peter Xu