From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 869344C62 for ; Fri, 3 Jan 2025 08:17:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735892251; cv=none; b=a2sqBCbcsZW3prCkE3QogZ8AqxEJUCDWra94pri7vANc25VlCLvVigbIBeioCgAIRSH+UusoHB7j+L1sCAFDgDQ9AW/oS0BM9evoiO9cP9yCwIQM2AiSYJC+iqgvpPsxVbpAGLyHTBo5bi91j8Mb9Ndcb75/B7/DynhjQPW4sUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735892251; c=relaxed/simple; bh=KRn8zNZ4xbOHK2LZ0Rj+jJcazNiR6nRsd3657M0lNfE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IdTgD3sfHBr0uWy95VJcMwP5h6axjI5iW9zSFYjh4xQEn7uYVVrIIVCXEboEWSLMWs/9g2CkmiMYnzJp3pDwRAXMTWMzQlJLF/eLrL823ctKPtCgRAQKxr5PWUxKmymihpum5X3Sx11l06r6/qMNkDF0AbjFzN1jvqtb1M+A60w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7D8E9150C; Fri, 3 Jan 2025 00:17:56 -0800 (PST) Received: from [10.162.41.37] (K4MQJ0H1H2.blr.arm.com [10.162.41.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6BBD83F673; Fri, 3 Jan 2025 00:17:18 -0800 (PST) Message-ID: <7e89702d-c52c-4716-9cd6-33aebade1c71@arm.com> Date: Fri, 3 Jan 2025 13:47:15 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 09/12] khugepaged: Introduce vma_collapse_anon_folio() To: David Hildenbrand , akpm@linux-foundation.org, willy@infradead.org, kirill.shutemov@linux.intel.com Cc: ryan.roberts@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, jack@suse.cz, srivatsa@csail.mit.edu, haowenchao22@gmail.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, ioworker0@gmail.com, wangkefeng.wang@huawei.com, ziy@nvidia.com, jglisse@google.com, surenb@google.com, vishal.moola@gmail.com, zokeefe@google.com, zhengqi.arch@bytedance.com, jhubbard@nvidia.com, 21cnbao@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20241216165105.56185-1-dev.jain@arm.com> <20241216165105.56185-10-dev.jain@arm.com> <2215dd8e-233a-427b-b15c-a2ffbce8f46d@redhat.com> <28013908-65d8-462e-b975-cd0f63d226b1@arm.com> <0368f4f2-cb0f-4633-a86d-5c3f75839b4e@redhat.com> <8d752d25-b9b2-4bf9-9a81-254aeb3ab0f6@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/01/25 5:03 pm, David Hildenbrand wrote: >>>> >>>> When having to back-off (restore original PTEs), or for copying, >>>> you'll likely need access to the original PTEs, which were already >>>> cleared. So likely you need a temporary copy of the original PTEs >>>> somehow. >>>> >>>> That's why temporarily clearing the PMD und mmap write lock is easier >>>> to implement, at the cost of requiring the mmap lock in write mode >>>> like PMD collapse. >> >> Why do I need to clear the PMD if I am taking the mmap_write_lock() and >> operating only on the PTE? > > One approach I proposed to Nico (and I think he has a prototype) is: > > a) Take all locks like we do today (mmap in write, vma in write, rmap > in write) > > After this step, no "ordinary" page table walkers can run anymore > > b) Clear the PMD entry and flush the TLB like we do today > > After this step, neither the CPU can read/write folios nor GUP-fast > can run. The PTE table is completely isolated. > > c) Now we can work on the (temporarily cleared) PTE table as we > please: isolate folios, lock them, ... without clearing the PTE > entries, just like we do today. > > d) Allocate the new folios (we don't have to hold any spinlocks), copy > + replace the affected PTE entries in the isolated PTE table. Similar > to what we do today, except that we don't clear PTEs but instead > clear+reset. > > e) Unlock+un-isolate + unref the collapsed folios like we do today. > > f) Re-map the PTE-table, like we do today when collapse would have > failed. > > > Of course, after taking all locks we have to re-verify that there is > something to collapse (e.g., in d) we also have to check for > unexpected folio references). The backup path is easy: remap the PTE > table as no PTE entries were touched just yet. > > Observe that many things are "like we do today". > > > As soon as we go to read locks + PTE locks, it all gets more > complicated to get it right. Not that it cannot be done, but the above > is IMHO a lot simpler to get right. Thanks for the reply. I'll go ahead with the write lock algorithm then.