All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michal Hocko <mhocko@suse.cz>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Rui Teng <rui.teng@linux.vnet.ibm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 0/1] memory offline issues with hugepage size > memory block size
Date: Wed, 21 Sep 2016 12:30:35 +0200	[thread overview]
Message-ID: <20160921123035.02ac4a2a@thinkpad> (raw)
In-Reply-To: <bc000c05-3186-da92-e868-f2dbf0c28a98@oracle.com>

On Tue, 20 Sep 2016 10:37:04 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:

> 
> Cc'ed Rui Teng and Dave Hansen as they were discussing the issue in
> this thread:
> https://lkml.org/lkml/2016/9/13/146

Ah, thanks, I didn't see that.

> 
> Their approach (I believe) would be to fail the offline operation in
> this case.  However, I could argue that failing the operation, or
> dissolving the unused huge page containing the area to be offlined is
> the right thing to do.
> 
> I never thought too much about the VM_BUG_ON(), but you are correct in
> that it should be removed in either case.
> 
> The other thing that needs to be changed is the locking in
> dissolve_free_huge_page().  I believe the lock only needs to be held if
> we are removing the huge page from the pool.  It is not a correctness
> but performance issue.
> 

Yes, that looks odd, that's why in my patch I moved the PageHuge() check
out from dissolve_free_huge_page(), up into the loop in
dissolve_free_huge_pages(). This way dissolve_free_huge_page() with its
locking should only be called once per memory block, in the case where
this memory block is part of a gigantic hugepage.

WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michal Hocko <mhocko@suse.cz>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Rui Teng <rui.teng@linux.vnet.ibm.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH 0/1] memory offline issues with hugepage size > memory block size
Date: Wed, 21 Sep 2016 12:30:35 +0200	[thread overview]
Message-ID: <20160921123035.02ac4a2a@thinkpad> (raw)
In-Reply-To: <bc000c05-3186-da92-e868-f2dbf0c28a98@oracle.com>

On Tue, 20 Sep 2016 10:37:04 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:

> 
> Cc'ed Rui Teng and Dave Hansen as they were discussing the issue in
> this thread:
> https://lkml.org/lkml/2016/9/13/146

Ah, thanks, I didn't see that.

> 
> Their approach (I believe) would be to fail the offline operation in
> this case.  However, I could argue that failing the operation, or
> dissolving the unused huge page containing the area to be offlined is
> the right thing to do.
> 
> I never thought too much about the VM_BUG_ON(), but you are correct in
> that it should be removed in either case.
> 
> The other thing that needs to be changed is the locking in
> dissolve_free_huge_page().  I believe the lock only needs to be held if
> we are removing the huge page from the pool.  It is not a correctness
> but performance issue.
> 

Yes, that looks odd, that's why in my patch I moved the PageHuge() check
out from dissolve_free_huge_page(), up into the loop in
dissolve_free_huge_pages(). This way dissolve_free_huge_page() with its
locking should only be called once per memory block, in the case where
this memory block is part of a gigantic hugepage.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2016-09-21 10:30 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 15:53 [PATCH 0/1] memory offline issues with hugepage size > memory block size Gerald Schaefer
2016-09-20 15:53 ` Gerald Schaefer
2016-09-20 15:53 ` [PATCH 1/1] mm/hugetlb: fix memory offline " Gerald Schaefer
2016-09-20 15:53   ` Gerald Schaefer
2016-09-21  6:29   ` Hillf Danton
2016-09-21  6:29     ` Hillf Danton
2016-09-21 12:35     ` [PATCH v2 " Gerald Schaefer
2016-09-21 12:35       ` Gerald Schaefer
2016-09-21 13:17       ` Rui Teng
2016-09-21 13:17         ` Rui Teng
2016-09-21 15:13         ` Gerald Schaefer
2016-09-21 15:13           ` Gerald Schaefer
2016-09-22  7:58       ` Hillf Danton
2016-09-22  7:58         ` Hillf Danton
2016-09-22  9:51       ` Michal Hocko
2016-09-22  9:51         ` Michal Hocko
2016-09-22 13:45         ` Gerald Schaefer
2016-09-22 13:45           ` Gerald Schaefer
2016-09-22 16:29           ` [PATCH v3] " Gerald Schaefer
2016-09-22 16:29             ` Gerald Schaefer
2016-09-22 18:12             ` Dave Hansen
2016-09-22 18:12               ` Dave Hansen
2016-09-22 19:13               ` Mike Kravetz
2016-09-22 19:13                 ` Mike Kravetz
2016-09-23 10:36               ` Gerald Schaefer
2016-09-23 10:36                 ` Gerald Schaefer
2016-09-23  6:40         ` [PATCH v2 1/1] " Rui Teng
2016-09-23  6:40           ` Rui Teng
2016-09-23 11:03           ` Gerald Schaefer
2016-09-23 11:03             ` Gerald Schaefer
2016-09-26  2:49             ` Rui Teng
2016-09-26  2:49               ` Rui Teng
2016-09-20 17:37 ` [PATCH 0/1] memory offline issues " Mike Kravetz
2016-09-20 17:37   ` Mike Kravetz
2016-09-20 17:45   ` Dave Hansen
2016-09-20 17:45     ` Dave Hansen
2016-09-21  9:49     ` Vlastimil Babka
2016-09-21  9:49       ` Vlastimil Babka
2016-09-21 10:34     ` Gerald Schaefer
2016-09-21 10:34       ` Gerald Schaefer
2016-09-21 10:30   ` Gerald Schaefer [this message]
2016-09-21 10:30     ` Gerald Schaefer
2016-09-21 18:20   ` Michal Hocko
2016-09-21 18:20     ` Michal Hocko
2016-09-21 18:27     ` Dave Hansen
2016-09-21 18:27       ` Dave Hansen
2016-09-21 19:22       ` Michal Hocko
2016-09-21 19:22         ` Michal Hocko

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=20160921123035.02ac4a2a@thinkpad \
    --to=gerald.schaefer@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=rui.teng@linux.vnet.ibm.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=vbabka@suse.cz \
    /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.