All of lore.kernel.org
 help / color / mirror / Atom feed
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;

  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: link
Be 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.