From: Mel Gorman <mgorman@suse.de>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: David Rientjes <rientjes@google.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Andi Kleen <andi@firstfloor.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option
Date: Wed, 12 Feb 2014 10:39:24 +0000 [thread overview]
Message-ID: <20140212103924.GO6732@suse.de> (raw)
In-Reply-To: <20140211201557.GA16281@amt.cnet>
On Tue, Feb 11, 2014 at 06:15:57PM -0200, Marcelo Tosatti wrote:
> On Tue, Feb 11, 2014 at 05:10:35PM +0000, Mel Gorman wrote:
> > On Tue, Feb 11, 2014 at 01:26:29PM -0200, Marcelo Tosatti wrote:
> > > > Or take a stab at allocating 1G pages at runtime. It would require
> > > > finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGES at
> > > > runtime. I would expect it would only work very early in the lifetime of
> > > > the system but if the user is willing to use kernel parameters to
> > > > allocate them then it should not be an issue.
> > >
> > > Can be an improvement on top of the current patchset? Certain use-cases
> > > require allocation guarantees (even if that requires kernel parameters).
> > >
> >
> > Sure, they're not mutually exclusive. It would just avoid the need to
> > create a new kernel parameter and use the existing interfaces.
>
> Yes, the problem is there is no guarantee is there?
>
There is no guarantee anyway and early in the lifetime of the system there
is going to be very little difference in success rates. In case there is a
misunderstanding here, I'm not looking to NAK a series that adds another
kernel parameter. If it was me, I would have tried runtime allocation
first to avoid adding a new interface but it's a personal preference.
--
Mel Gorman
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>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: David Rientjes <rientjes@google.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Andi Kleen <andi@firstfloor.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option
Date: Wed, 12 Feb 2014 10:39:24 +0000 [thread overview]
Message-ID: <20140212103924.GO6732@suse.de> (raw)
In-Reply-To: <20140211201557.GA16281@amt.cnet>
On Tue, Feb 11, 2014 at 06:15:57PM -0200, Marcelo Tosatti wrote:
> On Tue, Feb 11, 2014 at 05:10:35PM +0000, Mel Gorman wrote:
> > On Tue, Feb 11, 2014 at 01:26:29PM -0200, Marcelo Tosatti wrote:
> > > > Or take a stab at allocating 1G pages at runtime. It would require
> > > > finding properly aligned 1Gs worth of contiguous MAX_ORDER_NR_PAGES at
> > > > runtime. I would expect it would only work very early in the lifetime of
> > > > the system but if the user is willing to use kernel parameters to
> > > > allocate them then it should not be an issue.
> > >
> > > Can be an improvement on top of the current patchset? Certain use-cases
> > > require allocation guarantees (even if that requires kernel parameters).
> > >
> >
> > Sure, they're not mutually exclusive. It would just avoid the need to
> > create a new kernel parameter and use the existing interfaces.
>
> Yes, the problem is there is no guarantee is there?
>
There is no guarantee anyway and early in the lifetime of the system there
is going to be very little difference in success rates. In case there is a
misunderstanding here, I'm not looking to NAK a series that adds another
kernel parameter. If it was me, I would have tried runtime allocation
first to avoid adding a new interface but it's a personal preference.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2014-02-12 10:39 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-10 17:27 [PATCH 0/4] hugetlb: add hugepagesnid= command-line option Luiz Capitulino
2014-02-10 17:27 ` Luiz Capitulino
2014-02-10 17:27 ` [PATCH 1/4] memblock: memblock_virt_alloc_internal(): alloc from specified node only Luiz Capitulino
2014-02-10 17:27 ` Luiz Capitulino
2014-02-10 23:27 ` Andrew Morton
2014-02-10 23:27 ` Andrew Morton
2014-02-11 9:20 ` Mel Gorman
2014-02-11 9:20 ` Mel Gorman
2014-02-10 17:27 ` [PATCH 2/4] memblock: add memblock_virt_alloc_nid_nopanic() Luiz Capitulino
2014-02-10 17:27 ` Luiz Capitulino
2014-02-10 17:27 ` [PATCH 3/4] hugetlb: add hugepagesnid= command-line option Luiz Capitulino
2014-02-10 17:27 ` Luiz Capitulino
2014-02-10 23:27 ` Andrew Morton
2014-02-10 23:27 ` Andrew Morton
2014-02-11 15:26 ` Luiz Capitulino
2014-02-11 15:26 ` Luiz Capitulino
2014-02-12 3:44 ` Yasuaki Ishimatsu
2014-02-12 3:44 ` Yasuaki Ishimatsu
2014-02-12 19:39 ` Luiz Capitulino
2014-02-12 19:39 ` Luiz Capitulino
2014-02-10 17:27 ` [PATCH 4/4] hugetlb: hugepagesnid=: add 1G huge page support Luiz Capitulino
2014-02-10 17:27 ` Luiz Capitulino
2014-02-10 23:30 ` Andrew Morton
2014-02-10 23:30 ` Andrew Morton
2014-02-11 15:27 ` Luiz Capitulino
2014-02-11 15:27 ` Luiz Capitulino
2014-02-10 17:55 ` [PATCH 0/4] hugetlb: add hugepagesnid= command-line option Luiz Capitulino
2014-02-10 17:55 ` Luiz Capitulino
2014-02-10 23:13 ` Andrew Morton
2014-02-10 23:13 ` Andrew Morton
2014-02-11 3:58 ` Davidlohr Bueso
2014-02-11 3:58 ` Davidlohr Bueso
2014-02-11 15:10 ` Luiz Capitulino
2014-02-11 15:10 ` Luiz Capitulino
2014-02-11 2:54 ` David Rientjes
2014-02-11 2:54 ` David Rientjes
2014-02-11 9:25 ` Mel Gorman
2014-02-11 9:25 ` Mel Gorman
2014-02-11 15:26 ` Marcelo Tosatti
2014-02-11 15:26 ` Marcelo Tosatti
2014-02-11 17:10 ` Mel Gorman
2014-02-11 17:10 ` Mel Gorman
2014-02-11 20:15 ` Marcelo Tosatti
2014-02-11 20:15 ` Marcelo Tosatti
2014-02-12 10:39 ` Mel Gorman [this message]
2014-02-12 10:39 ` Mel Gorman
2014-02-11 15:36 ` Luiz Capitulino
2014-02-11 15:36 ` Luiz Capitulino
2014-02-12 3:59 ` David Rientjes
2014-02-12 3:59 ` David Rientjes
2014-02-12 20:09 ` Luiz Capitulino
2014-02-12 20:09 ` Luiz Capitulino
2014-02-11 21:17 ` Andi Kleen
2014-02-11 21:17 ` Andi Kleen
2014-02-11 21:31 ` Luiz Capitulino
2014-02-11 21:31 ` Luiz Capitulino
2014-02-12 2:37 ` Andi Kleen
2014-02-12 2:37 ` Andi Kleen
2014-02-12 4:01 ` David Rientjes
2014-02-12 4:01 ` David Rientjes
2014-02-12 19:33 ` Luiz Capitulino
2014-02-12 19:33 ` Luiz Capitulino
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=20140212103924.GO6732@suse.de \
--to=mgorman@suse.de \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mtosatti@redhat.com \
--cc=riel@redhat.com \
--cc=rientjes@google.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.