From: Anshuman Khandual <anshuman.khandual@arm.com> To: Michal Hocko <mhocko@kernel.org> Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, punit.agrawal@arm.com, will.deacon@arm.com, Steven.Price@arm.com, catalin.marinas@arm.com, mike.kravetz@oracle.com, n-horiguchi@ah.jp.nec.com Subject: Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration Date: Fri, 5 Oct 2018 13:04:43 +0530 [thread overview] Message-ID: <5dc1dc4d-de60-43b9-aab6-3b3bb6a22a4b@arm.com> (raw) In-Reply-To: <20181003133609.GG4714@dhcp22.suse.cz> On 10/03/2018 07:06 PM, Michal Hocko wrote: > On Wed 03-10-18 18:36:39, Anshuman Khandual wrote: > [...] >> So we have two checks here >> >> 1) platform specific arch_hugetlb_migration -> In principle go ahead >> >> 2) huge_movable() during allocation >> >> - If huge page does not have to be placed on movable zone >> >> - Allocate any where successfully and done ! >> >> - If huge page *should* be placed on a movable zone >> >> - Try allocating on movable zone >> >> - Successfull and done ! >> >> - If the new page could not be allocated on movable zone >> >> - Abort the migration completely >> >> OR >> >> - Warn and fall back to non-movable > > I guess you are still making it more complicated than necessary. The > later is really only about __GFP_MOVABLE at this stage. I would just > make it simple for now. We do not have to implement any dynamic > heuristic right now. All that I am asking for is to split the migrate > possible part from movable part. > > I should have been more clear about that I guess from my very first > reply. I do like how you moved the current coarse grained > hugepage_migration_supported to be more arch specific but I merely > wanted to point out that we need to do some other changes before we can > go that route and that thing is to distinguish movable from migration > supported. > > See my point? Does the following sound close enough to what you are looking for ? diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 9df1d59..070c419 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -504,6 +504,13 @@ static inline bool hugepage_migration_supported(struct hstate *h) return arch_hugetlb_migration_supported(h); } +static inline bool hugepage_movable_required(struct hstate *h) +{ + if (hstate_is_gigantic(h)) + return true; + return false; +} + static inline spinlock_t *huge_pte_lockptr(struct hstate *h, struct mm_struct *mm, pte_t *pte) { @@ -600,6 +607,11 @@ static inline bool hugepage_migration_supported(struct hstate *h) return false; } +static inline bool hugepage_movable_required(struct hstate *h) +{ + return false; +} + static inline spinlock_t *huge_pte_lockptr(struct hstate *h, struct mm_struct *mm, pte_t *pte) { diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 3c21775..8b0afdc 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1635,6 +1635,9 @@ struct page *alloc_huge_page_node(struct hstate *h, int nid) if (nid != NUMA_NO_NODE) gfp_mask |= __GFP_THISNODE; + if (hugepage_movable_required(h)) + gfp_mask |= __GFP_MOVABLE; + spin_lock(&hugetlb_lock); if (h->free_huge_pages - h->resv_huge_pages > 0) page = dequeue_huge_page_nodemask(h, gfp_mask, nid, NULL); @@ -1652,6 +1655,9 @@ struct page *alloc_huge_page_nodemask(struct hstate *h, int preferred_nid, { gfp_t gfp_mask = htlb_alloc_mask(h); + if (hugepage_movable_required(h)) + gfp_mask |= __GFP_MOVABLE; + spin_lock(&hugetlb_lock); if (h->free_huge_pages - h->resv_huge_pages > 0) { struct page *page;
WARNING: multiple messages have this Message-ID (diff)
From: anshuman.khandual@arm.com (Anshuman Khandual) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration Date: Fri, 5 Oct 2018 13:04:43 +0530 [thread overview] Message-ID: <5dc1dc4d-de60-43b9-aab6-3b3bb6a22a4b@arm.com> (raw) In-Reply-To: <20181003133609.GG4714@dhcp22.suse.cz> On 10/03/2018 07:06 PM, Michal Hocko wrote: > On Wed 03-10-18 18:36:39, Anshuman Khandual wrote: > [...] >> So we have two checks here >> >> 1) platform specific arch_hugetlb_migration -> In principle go ahead >> >> 2) huge_movable() during allocation >> >> - If huge page does not have to be placed on movable zone >> >> - Allocate any where successfully and done ! >> >> - If huge page *should* be placed on a movable zone >> >> - Try allocating on movable zone >> >> - Successfull and done ! >> >> - If the new page could not be allocated on movable zone >> >> - Abort the migration completely >> >> OR >> >> - Warn and fall back to non-movable > > I guess you are still making it more complicated than necessary. The > later is really only about __GFP_MOVABLE at this stage. I would just > make it simple for now. We do not have to implement any dynamic > heuristic right now. All that I am asking for is to split the migrate > possible part from movable part. > > I should have been more clear about that I guess from my very first > reply. I do like how you moved the current coarse grained > hugepage_migration_supported to be more arch specific but I merely > wanted to point out that we need to do some other changes before we can > go that route and that thing is to distinguish movable from migration > supported. > > See my point? Does the following sound close enough to what you are looking for ? diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 9df1d59..070c419 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -504,6 +504,13 @@ static inline bool hugepage_migration_supported(struct hstate *h) return arch_hugetlb_migration_supported(h); } +static inline bool hugepage_movable_required(struct hstate *h) +{ + if (hstate_is_gigantic(h)) + return true; + return false; +} + static inline spinlock_t *huge_pte_lockptr(struct hstate *h, struct mm_struct *mm, pte_t *pte) { @@ -600,6 +607,11 @@ static inline bool hugepage_migration_supported(struct hstate *h) return false; } +static inline bool hugepage_movable_required(struct hstate *h) +{ + return false; +} + static inline spinlock_t *huge_pte_lockptr(struct hstate *h, struct mm_struct *mm, pte_t *pte) { diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 3c21775..8b0afdc 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1635,6 +1635,9 @@ struct page *alloc_huge_page_node(struct hstate *h, int nid) if (nid != NUMA_NO_NODE) gfp_mask |= __GFP_THISNODE; + if (hugepage_movable_required(h)) + gfp_mask |= __GFP_MOVABLE; + spin_lock(&hugetlb_lock); if (h->free_huge_pages - h->resv_huge_pages > 0) page = dequeue_huge_page_nodemask(h, gfp_mask, nid, NULL); @@ -1652,6 +1655,9 @@ struct page *alloc_huge_page_nodemask(struct hstate *h, int preferred_nid, { gfp_t gfp_mask = htlb_alloc_mask(h); + if (hugepage_movable_required(h)) + gfp_mask |= __GFP_MOVABLE; + spin_lock(&hugetlb_lock); if (h->free_huge_pages - h->resv_huge_pages > 0) { struct page *page;
next prev parent reply other threads:[~2018-10-05 7:34 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-02 12:15 [PATCH 0/4] arm64/mm: Enable HugeTLB migration Anshuman Khandual 2018-10-02 12:15 ` Anshuman Khandual 2018-10-02 12:15 ` [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration Anshuman Khandual 2018-10-02 12:15 ` Anshuman Khandual 2018-10-02 12:38 ` Suzuki K Poulose 2018-10-02 12:38 ` Suzuki K Poulose 2018-10-02 12:56 ` Anshuman Khandual 2018-10-02 12:56 ` Anshuman Khandual 2018-10-02 12:56 ` Anshuman Khandual 2018-10-03 10:22 ` Suzuki K Poulose 2018-10-03 10:22 ` Suzuki K Poulose 2018-10-03 10:22 ` Suzuki K Poulose 2018-10-03 11:10 ` Anshuman Khandual 2018-10-03 11:10 ` Anshuman Khandual 2018-10-03 11:10 ` Anshuman Khandual 2018-10-03 11:17 ` Suzuki K Poulose 2018-10-03 11:17 ` Suzuki K Poulose 2018-10-03 11:17 ` Suzuki K Poulose 2018-10-03 11:27 ` Michal Hocko 2018-10-03 11:27 ` Michal Hocko 2018-10-02 12:39 ` Michal Hocko 2018-10-02 12:39 ` Michal Hocko 2018-10-03 2:16 ` Anshuman Khandual 2018-10-03 2:16 ` Anshuman Khandual 2018-10-03 6:58 ` Michal Hocko 2018-10-03 6:58 ` Michal Hocko 2018-10-03 9:58 ` Anshuman Khandual 2018-10-03 9:58 ` Anshuman Khandual 2018-10-03 10:59 ` Michal Hocko 2018-10-03 10:59 ` Michal Hocko 2018-10-03 11:37 ` Anshuman Khandual 2018-10-03 11:37 ` Anshuman Khandual 2018-10-03 11:48 ` Michal Hocko 2018-10-03 11:48 ` Michal Hocko 2018-10-03 13:06 ` Anshuman Khandual 2018-10-03 13:06 ` Anshuman Khandual 2018-10-03 13:36 ` Michal Hocko 2018-10-03 13:36 ` Michal Hocko 2018-10-05 7:34 ` Anshuman Khandual [this message] 2018-10-05 7:34 ` Anshuman Khandual 2018-10-09 14:14 ` Michal Hocko 2018-10-09 14:14 ` Michal Hocko 2018-10-10 3:09 ` Anshuman Khandual 2018-10-10 3:09 ` Anshuman Khandual 2018-10-10 9:39 ` Michal Hocko 2018-10-10 9:39 ` Michal Hocko 2018-10-11 3:16 ` Anshuman Khandual 2018-10-11 3:16 ` Anshuman Khandual 2018-10-02 12:15 ` [PATCH 2/4] mm/hugetlb: Enable arch specific huge page size support for migration Anshuman Khandual 2018-10-02 12:15 ` Anshuman Khandual 2018-10-02 12:15 ` [PATCH 3/4] arm64/mm: Enable HugeTLB migration Anshuman Khandual 2018-10-02 12:15 ` Anshuman Khandual 2018-10-02 12:15 ` [PATCH 4/4] arm64/mm: Enable HugeTLB migration for contiguous bit HugeTLB pages Anshuman Khandual 2018-10-02 12:15 ` Anshuman Khandual
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5dc1dc4d-de60-43b9-aab6-3b3bb6a22a4b@arm.com \ --to=anshuman.khandual@arm.com \ --cc=Steven.Price@arm.com \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=mike.kravetz@oracle.com \ --cc=n-horiguchi@ah.jp.nec.com \ --cc=punit.agrawal@arm.com \ --cc=suzuki.poulose@arm.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.