From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yin Fengwei <fengwei.yin@intel.com>
Subject: Re: [PATCH v1 00/10] variable-order, large folios for anonymous
 memory
Date: Thu, 29 Jun 2023 08:31:00 +0800
Message-ID: <e8357d56-ab58-3268-e074-a4c494d4697f@intel.com>
References: <20230626171430.3167004-1-ryan.roberts@arm.com>
 <CAOUHufaUTbUw9MTzw8D=sVrEB+RP6LSBQVGn93TWk=ozV8XobA@mail.gmail.com>
 <CAOUHufa0S_ayrys0XzDbH8KJi5HxvbGCh_bSAhDpAgcmSJjFUQ@mail.gmail.com>
 <1fb0c4cb-a709-de20-d643-32ed43550059@arm.com>
 <CAOUHufbtNPkdktjt_5qM45GegVO-rCFOMkSh0HQminQ12zsV8Q@mail.gmail.com>
 <dcbbea37-7fbf-3a7c-6cfb-04dae715e967@intel.com>
 <CAOUHufbC76OdP16mRsY3i920qB7khcu8FM+nUOG0kx5BMRdKXw@mail.gmail.com>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Return-path: <linux-ia64-owner@vger.kernel.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
  t=1687998680; x=1719534680;
  h=message-id:date:subject:to:cc:references:from:
   in-reply-to:content-transfer-encoding:mime-version;
  bh=BICH5n8MxFZryEEiFlmvkNuBrIOFHh1powT/aC+78IA=;
  b=UaYsbVsgCtMKfTySWyBxTsTQsgZKHJ5V5WMwT0OxbwHlfWrO1BFelG8Y
   W+zF2gNtYX4VVvLF4oq3DkWmZVa8oSl1Uk0qSlafIlZcLnSO4beRD2VZm
   l1pNftV8KkWAZNV3q+aOJA71l/7irlgfDyjxPHNPc6WX4HtX09XjF/OXY
   taXrmJDV8+2nxcOMFaLTr4dZ5Zys9Y4VzEZQ+SsFH1AZpiRm4BQgrsskH
   gptJuPLumx3ktD4kaUeOlAikM2pengFquI68cYPNuqNFxklKLLUf9ZmRZ
   QSrVMK55M52pFBR+8b/+JD+G9zy4wufljJ+JiPbYF9BDisng2I9z+zY6i
   Q==;
Content-Language: en-US
In-Reply-To: <CAOUHufbC76OdP16mRsY3i920qB7khcu8FM+nUOG0kx5BMRdKXw@mail.gmail.com>
List-ID: <linux-alpha.vger.kernel.org>
Content-Type: text/plain; charset="windows-1252"
To: Yu Zhao <yuzhao@google.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>, Andrew Morton <akpm@linux-foundation.org>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, David Hildenbrand <david@redhat.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Geert Uytterhoeven <geert@linux-m68k.org>, Christian Borntraeger <borntraeger@linux.ibm.com>, Sven Schnelle <svens@linux.ibm.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, lin



On 6/29/23 08:27, Yu Zhao wrote:
> On Wed, Jun 28, 2023 at 5:59=E2=80=AFPM Yin Fengwei <fengwei.yin@intel.co=
m> wrote:
>>
>> Hi Yu,
>>
>> On 6/29/23 02:22, Yu Zhao wrote:
>>> And please make sure it's disabled by default, because we are still
>>> missing many important functions, e.g., I don't think we can mlock()
>>> when large() && !pmd_mappable(), see mlock_pte_range() and
>>> mlock_vma_folio(). We can fix it along with many things later, but we
>>> need to present a plan and a schedule now. Otherwise, there would be
>>> pushback if we try to land the series without supporting mlock().
>>>
>>> Do you or Fengwei plan to take on it? (I personally don't.) If not,
>> Do you mean the mlock() with large folio? Yes. I can work on it. Thanks.
>=20
> Great. Thanks!
>=20
> Other places that have the similar problem but are probably easier to
> fix than the mlock() case:
> * madvise_cold_or_pageout_pte_range()
This one was on my radar. :).=20

Regards
Yin, Fengwei

> * shrink_folio_list()