From: Michal Hocko <mhocko@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Mike Kravetz <mike.kravetz@oracle.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Santhosh G <santhog4@in.ibm.com>
Subject: Re: [PATCH] memory-hotplug: Fix bad area access on dissolve_free_huge_pages()
Date: Wed, 21 Sep 2016 18:27:16 +0200 [thread overview]
Message-ID: <20160921162715.GC24210@dhcp22.suse.cz> (raw)
In-Reply-To: <57E2AF8F.6030202@linux.intel.com>
On Wed 21-09-16 09:04:31, Dave Hansen wrote:
> On 09/21/2016 05:05 AM, Michal Hocko wrote:
> > On Tue 20-09-16 10:43:13, Dave Hansen wrote:
> >> On 09/20/2016 08:52 AM, Rui Teng wrote:
> >>> On 9/20/16 10:53 PM, Dave Hansen wrote:
> >> ...
> >>>> That's good, but aren't we still left with a situation where we've
> >>>> offlined and dissolved the _middle_ of a gigantic huge page while the
> >>>> head page is still in place and online?
> >>>>
> >>>> That seems bad.
> >>>>
> >>> What about refusing to change the status for such memory block, if it
> >>> contains a huge page which larger than itself? (function
> >>> memory_block_action())
> >>
> >> How will this be visible to users, though? That sounds like you simply
> >> won't be able to offline memory with gigantic huge pages.
> >
> > I might be missing something but Is this any different from a regular
> > failure when the memory cannot be freed? I mean
> > /sys/devices/system/memory/memory API doesn't give you any hint whether
> > the memory in the particular block is used and
> > unmigrateable.
>
> It's OK to have free hugetlbfs pages in an area that's being offline'd.
> If we did that, it would not be OK to have a free gigantic hugetlbfs
> page that's larger than the area being offlined.
That was not my point. I wasn't very clear probably. Offlining can fail
which shouldn't be really surprising. There might be a kernel allocation
in the particular block which cannot be migrated so failures are to be
expected. I just do not see how offlining in the middle of a gigantic
page is any different from having any other unmovable allocation in a
block. That being said, why don't we simply refuse to offline a block
which is in the middle of a gigantic page.
> It would be a wee bit goofy to have the requirement that userspace go
> find all the gigantic pages and make them non-gigantic before trying to
> offline something.
yes
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Mike Kravetz <mike.kravetz@oracle.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
Santhosh G <santhog4@in.ibm.com>
Subject: Re: [PATCH] memory-hotplug: Fix bad area access on dissolve_free_huge_pages()
Date: Wed, 21 Sep 2016 18:27:16 +0200 [thread overview]
Message-ID: <20160921162715.GC24210@dhcp22.suse.cz> (raw)
In-Reply-To: <57E2AF8F.6030202@linux.intel.com>
On Wed 21-09-16 09:04:31, Dave Hansen wrote:
> On 09/21/2016 05:05 AM, Michal Hocko wrote:
> > On Tue 20-09-16 10:43:13, Dave Hansen wrote:
> >> On 09/20/2016 08:52 AM, Rui Teng wrote:
> >>> On 9/20/16 10:53 PM, Dave Hansen wrote:
> >> ...
> >>>> That's good, but aren't we still left with a situation where we've
> >>>> offlined and dissolved the _middle_ of a gigantic huge page while the
> >>>> head page is still in place and online?
> >>>>
> >>>> That seems bad.
> >>>>
> >>> What about refusing to change the status for such memory block, if it
> >>> contains a huge page which larger than itself? (function
> >>> memory_block_action())
> >>
> >> How will this be visible to users, though? That sounds like you simply
> >> won't be able to offline memory with gigantic huge pages.
> >
> > I might be missing something but Is this any different from a regular
> > failure when the memory cannot be freed? I mean
> > /sys/devices/system/memory/memory API doesn't give you any hint whether
> > the memory in the particular block is used and
> > unmigrateable.
>
> It's OK to have free hugetlbfs pages in an area that's being offline'd.
> If we did that, it would not be OK to have a free gigantic hugetlbfs
> page that's larger than the area being offlined.
That was not my point. I wasn't very clear probably. Offlining can fail
which shouldn't be really surprising. There might be a kernel allocation
in the particular block which cannot be migrated so failures are to be
expected. I just do not see how offlining in the middle of a gigantic
page is any different from having any other unmovable allocation in a
block. That being said, why don't we simply refuse to offline a block
which is in the middle of a gigantic page.
> It would be a wee bit goofy to have the requirement that userspace go
> find all the gigantic pages and make them non-gigantic before trying to
> offline something.
yes
--
Michal Hocko
SUSE Labs
--
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>
next prev parent reply other threads:[~2016-09-21 16:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 8:39 [PATCH] memory-hotplug: Fix bad area access on dissolve_free_huge_pages() Rui Teng
2016-09-13 8:39 ` Rui Teng
2016-09-13 17:32 ` Dave Hansen
2016-09-13 17:32 ` Dave Hansen
2016-09-14 16:33 ` Rui Teng
2016-09-14 16:33 ` Rui Teng
2016-09-14 16:37 ` Dave Hansen
2016-09-14 16:37 ` Dave Hansen
2016-09-16 13:58 ` Rui Teng
2016-09-16 13:58 ` Rui Teng
2016-09-16 16:25 ` Dave Hansen
2016-09-16 16:25 ` Dave Hansen
2016-09-20 14:45 ` Rui Teng
2016-09-20 14:45 ` Rui Teng
2016-09-20 14:53 ` Dave Hansen
2016-09-20 14:53 ` Dave Hansen
2016-09-20 15:52 ` Rui Teng
2016-09-20 15:52 ` Rui Teng
2016-09-20 17:43 ` Dave Hansen
2016-09-20 17:43 ` Dave Hansen
2016-09-21 12:05 ` Michal Hocko
2016-09-21 12:05 ` Michal Hocko
2016-09-21 16:04 ` Dave Hansen
2016-09-21 16:04 ` Dave Hansen
2016-09-21 16:27 ` Michal Hocko [this message]
2016-09-21 16:27 ` Michal Hocko
2016-09-21 16:32 ` Dave Hansen
2016-09-21 16:32 ` Dave Hansen
2016-09-21 16:52 ` Michal Hocko
2016-09-21 16:52 ` 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=20160921162715.GC24210@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=paul.gortmaker@windriver.com \
--cc=rui.teng@linux.vnet.ibm.com \
--cc=santhog4@in.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.