Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2681570ybb; Fri, 27 Mar 2020 10:05:53 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt+GlAIaEMI9sLNaYVYhzP1VQgobritvGMPKQu3OxTdGORRcZD1c+q6eOyz+thzMnM/wNhk X-Received: by 2002:aca:cc81:: with SMTP id c123mr4477650oig.74.1585328753670; Fri, 27 Mar 2020 10:05:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585328753; cv=none; d=google.com; s=arc-20160816; b=pM10Ccwa5DSMCirk8TkhbyA1Tjd6O2Xp3Mw6+0Cg0gV/xUKqiYx3PLRrgQHYlsGwj5 7F0QS/9JMENe5itfV5kN412vbxjHuboKQCzqig9rOvzw8oZu+1G8x/dR8m8gX+zXgzT6 z6Jcw3F62MepRsZS57m4QnScUrILtYRO+do8+7DKGkc2VgOOUnbLJDpivdTZ1brzqfxu kWG+Jgc9di8NJCBQzvJstVjgORjs0oUJ3bPwzItFMyHV2+4ChC6gkLvJ9nVhFjCsa2nJ L8MxZR+S6pWfFMmTfI3TgriKqmKFWQLY3yE4VuALirpgbNBx2vudCUTiFgpJhjj6jZ0K rvEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=iEb1i/1dam767tXvuNF7Sp30M1yJHeTtnfytL2XD9+0=; b=TylMB9Az3vuIMFHUSU0MQOpdfp48PJ9K041i/T8zRU2Abs0a9lhH4DDDFGSPR1+n/j hqPXQQH5a2SVXodAa14YsAMq9+bvjg5vjLUZXfDLmXxCvNleThu3jU5N3Z68AKbi/n5W FP1+7/dyrcvRFZa0LWciUtEzqsqllb4NO4SVWNDOP+eoWAit9+/GzxLb+DQxiVhVp/IA BDD7qRkLfvFDMeupdbdl4SX9PUdmHMTpdH6eoZWtDsMXxZyp/Kh+6YL/yWQ9trIL+/Yk wIEa/10ocI2lOJtS7i8QR+7yMNMszmyO5LjBv4OxWl4htAuR9gOYHVfBheqxpp4IqC32 AZEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=UKAxQ3og; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 109si2818361otv.36.2020.03.27.10.05.30; Fri, 27 Mar 2020 10:05:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=UKAxQ3og; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727738AbgC0RDz (ORCPT + 99 others); Fri, 27 Mar 2020 13:03:55 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:39440 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726515AbgC0RDz (ORCPT ); Fri, 27 Mar 2020 13:03:55 -0400 Received: by mail-lj1-f196.google.com with SMTP id i20so10967853ljn.6 for ; Fri, 27 Mar 2020 10:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=iEb1i/1dam767tXvuNF7Sp30M1yJHeTtnfytL2XD9+0=; b=UKAxQ3oghy+KZvU5JfMJspP8dHawVw7uDcnn47JgJG7naaZjSSbK3N/IV1OHC4LJiD y4XVmBqPEg8SEU+wmheP20Xupt0JU5rP9FMo9KWUEmky3NsncP1TBOc1V6LAv+cNI2MW hOb0MWLTA0sCb2gN8xaaF7IKfrgbtHv1VBtgI5alO0NUxnDbF47pj8AwJI2tCqaQKrqL ET+rtMfzfCxvwusObnkT4M6ZrFUOdSnbXV35HKtvOZGbxcZ3UPExH9BpRUL4A67zVJDt tCST/F2usiNPzXp8GA33dK4aj0lB5usiYOYRV9iU/g5UYYCBdV9GZfhgIFp+uZ5VkzXk 00xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=iEb1i/1dam767tXvuNF7Sp30M1yJHeTtnfytL2XD9+0=; b=rNd0BKJWrEyst8LXFtnQdAbRoOFRFj7+VeU85ePBTFJNJh34Y60ygJtt6AXmqzqk4O Yvez1632CxOZhjxhHwU0c8MN8ziv+TzxVun97j2u17y7kW2rjur3n0iKoeC41RxUs2/c Cfmu/4bIOlICUdWg4LZXlmRPcfEH3n/11yceKt7sKPR2ZgucT5r/TK9VOqlGhYKYnVMF K7BrDO1GXkT2sOKT3hjLxsOkPU+IzPtRt0Y/Rvypw8qDgIZL41cksnn2pU7vKOyw3B9y XveLDdBPHHCGG6bIEUaLOrOLikn4ZKetNUNC9sLmINnTBKN5I5W4KtkjjFxAFsvLDeUd +bdA== X-Gm-Message-State: ANhLgQ2Ehk9IbO1dpQNfATz6nSWoan7q+K6HQzDATbwdHbu8qdVj5wyn C9EZVGdiCb0DGfAL1lskhCXesw== X-Received: by 2002:a2e:b6c2:: with SMTP id m2mr8958115ljo.72.1585328631545; Fri, 27 Mar 2020 10:03:51 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id j125sm2083865lfj.38.2020.03.27.10.03.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2020 10:03:50 -0700 (PDT) From: "Kirill A. Shutemov" X-Google-Original-From: "Kirill A. Shutemov" Received: by box.localdomain (Postfix, from userid 1000) id 8BD32100D24; Fri, 27 Mar 2020 20:03:54 +0300 (+03) To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: [PATCH] thp: Simplify splitting PMD mapping huge zero page Date: Fri, 27 Mar 2020 20:03:53 +0300 Message-Id: <20200327170353.17734-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.26.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Splitting PMD mapping huge zero page can be simplified a lot: we can just unmap it and fallback to PTE handling. Signed-off-by: Kirill A. Shutemov --- mm/huge_memory.c | 57 ++++-------------------------------------------- 1 file changed, 4 insertions(+), 53 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 42407e16bd80..ef6a6bcb291f 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2114,40 +2114,6 @@ void __split_huge_pud(struct vm_area_struct *vma, pud_t *pud, } #endif /* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */ -static void __split_huge_zero_page_pmd(struct vm_area_struct *vma, - unsigned long haddr, pmd_t *pmd) -{ - struct mm_struct *mm = vma->vm_mm; - pgtable_t pgtable; - pmd_t _pmd; - int i; - - /* - * Leave pmd empty until pte is filled note that it is fine to delay - * notification until mmu_notifier_invalidate_range_end() as we are - * replacing a zero pmd write protected page with a zero pte write - * protected page. - * - * See Documentation/vm/mmu_notifier.rst - */ - pmdp_huge_clear_flush(vma, haddr, pmd); - - pgtable = pgtable_trans_huge_withdraw(mm, pmd); - pmd_populate(mm, &_pmd, pgtable); - - for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) { - pte_t *pte, entry; - entry = pfn_pte(my_zero_pfn(haddr), vma->vm_page_prot); - entry = pte_mkspecial(entry); - pte = pte_offset_map(&_pmd, haddr); - VM_BUG_ON(!pte_none(*pte)); - set_pte_at(mm, haddr, pte, entry); - pte_unmap(pte); - } - smp_wmb(); /* make pte visible before pmd */ - pmd_populate(mm, pmd, pgtable); -} - static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, unsigned long haddr, bool freeze) { @@ -2167,7 +2133,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, count_vm_event(THP_SPLIT_PMD); - if (!vma_is_anonymous(vma)) { + if (!vma_is_anonymous(vma) || is_huge_zero_pmd(*pmd)) { _pmd = pmdp_huge_clear_flush_notify(vma, haddr, pmd); /* * We are going to unmap this huge page. So @@ -2175,7 +2141,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, */ if (arch_needs_pgtable_deposit()) zap_deposited_table(mm, pmd); - if (vma_is_dax(vma)) + if (vma_is_dax(vma) || is_huge_zero_pmd(*pmd)) return; page = pmd_page(_pmd); if (!PageDirty(page) && pmd_dirty(_pmd)) @@ -2186,17 +2152,6 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, put_page(page); add_mm_counter(mm, mm_counter_file(page), -HPAGE_PMD_NR); return; - } else if (is_huge_zero_pmd(*pmd)) { - /* - * FIXME: Do we want to invalidate secondary mmu by calling - * mmu_notifier_invalidate_range() see comments below inside - * __split_huge_pmd() ? - * - * We are going from a zero huge page write protected to zero - * small page also write protected so it does not seems useful - * to invalidate secondary mmu at this time. - */ - return __split_huge_zero_page_pmd(vma, haddr, pmd); } /* @@ -2339,13 +2294,9 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd, spin_unlock(ptl); /* * No need to double call mmu_notifier->invalidate_range() callback. - * They are 3 cases to consider inside __split_huge_pmd_locked(): + * They are 2 cases to consider inside __split_huge_pmd_locked(): * 1) pmdp_huge_clear_flush_notify() call invalidate_range() obvious - * 2) __split_huge_zero_page_pmd() read only zero page and any write - * fault will trigger a flush_notify before pointing to a new page - * (it is fine if the secondary mmu keeps pointing to the old zero - * page in the meantime) - * 3) Split a huge pmd into pte pointing to the same page. No need + * 2) Split a huge pmd into pte pointing to the same page. No need * to invalidate secondary tlb entry they are all still valid. * any further changes to individual pte will notify. So no need * to call mmu_notifier->invalidate_range() -- 2.26.0