On Sat, 22 Feb 2014 05:03:50 +0100 Andi Kleen wrote:
> > But I think it would be better if it made hugepages= and hugepagesz=
> > obsolete, so we can emit a printk if people use those, telling them
> > to migrate because the old options are going away.
>
> Not sure why everyone wants to break ex
On Sat, 2014-02-22 at 05:03 +0100, Andi Kleen wrote:
> > But I think it would be better if it made hugepages= and hugepagesz=
> > obsolete, so we can emit a printk if people use those, telling them
> > to migrate because the old options are going away.
>
> Not sure why everyone wants to break exis
> But I think it would be better if it made hugepages= and hugepagesz=
> obsolete, so we can emit a printk if people use those, telling them
> to migrate because the old options are going away.
Not sure why everyone wants to break existing systems. These options
have existed for many years, you ca
On Mon, 17 Feb 2014 21:47:36 -0800 Davidlohr Bueso wrote:
> > How is that difficult? hugepages= is the "noun", hugepagesz= is the
> > "adjective". hugepages=100 hugepagesz=1G hugepages=4 makes perfect sense
> > to me, and I actually don't allocate hugepages on the command line, nor
> > have
> But, like I said, I'm not sure we'd ever be able to totally remove it
> because of backwards compatibility, but the point is that nobody would
> have to use it anymore as a hack for 1GB.
Again it's a perfectly fine and widely used interface. Any talk of removing
it is wrong.
-Andi
--
To unsub
On Fri, 21 Feb 2014, Andi Kleen wrote:
> > > 2) it improves the kernel command line interface from incomplete
> > > (lacking the ability to specify node<->page correlation), to
> > > a complete interface.
> > >
> >
> > If GB hugepages can be allocated dynamically, I really think we should be
>
> > 2) it improves the kernel command line interface from incomplete
> > (lacking the ability to specify node<->page correlation), to
> > a complete interface.
> >
>
> If GB hugepages can be allocated dynamically, I really think we should be
> able to remove hugepagesz= entirely for x86 after a
On Fri, 21 Feb 2014, Marcelo Tosatti wrote:
> > I agree that your customer wants a non-default distribution of 1GB
> > hugepages, yes, that's clear. The questions that have not been answered:
> > why must it be done this way as opposed to runtime? If 1GB hugepages
> > could be dynamically all
On Fri, Feb 21, 2014 at 02:07:08AM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > > 1GB is of such granularity that you'd typically either be (a) oom so that
> > > your userspace couldn't even start, or (b) have enough memory such that
> > > userspace would be a
On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
> > 1GB is of such granularity that you'd typically either be (a) oom so that
> > your userspace couldn't even start, or (b) have enough memory such that
> > userspace would be able to start and allocate them dynamically through an
> > initscript.
>
On Thu, 20 Feb 2014 15:15:46 -0800 (PST)
David Rientjes wrote:
> Do I really need to do your work for you and work on 1GB hugepages at
> runtime, which many more people would be interested in? Or are we just
> seeking the easiest way out here with something that shuts the customer up
> and le
On Thu, Feb 20, 2014 at 03:15:46PM -0800, David Rientjes wrote:
> On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
>
> > Mel has clearly has no objection to the command line. You can also
> > allocate 2M pages at runtime, and that is no reason for "hugepages="
> > interface to not exist.
> >
>
> The
On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
> > I'm not sure it's interesting to talk about since this patchset is
> > unnecessary if you can do it at runtime, but since "hugepagesz=" and
> > "hugepages=" have existed for many kernel releases, we must maintain
> > backwards compatibility. Thus
On Thu, 20 Feb 2014, Marcelo Tosatti wrote:
> Mel has clearly has no objection to the command line. You can also
> allocate 2M pages at runtime, and that is no reason for "hugepages="
> interface to not exist.
>
The "hugepages=" interface does exist and for good reason, when
fragmentation is s
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the kernel command line interface is a fi
On Wed, Feb 19, 2014 at 07:46:41PM -0800, David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the kernel command line interface is a fi
On Wed, 19 Feb 2014 20:51:55 -0800 (PST)
David Rientjes wrote:
> On Wed, 19 Feb 2014, Luiz Capitulino wrote:
>
> > > Yes, my concrete objection is that the command line interface is
> > > unnecessary if you can dynamically allocate and free 1GB pages at runtime
> > > unless memory will be so f
On Wed, 19 Feb 2014, Luiz Capitulino wrote:
> > Yes, my concrete objection is that the command line interface is
> > unnecessary if you can dynamically allocate and free 1GB pages at runtime
> > unless memory will be so fragmented that it cannot be done when userspace
> > is brought up. That i
On Wed, 19 Feb 2014 19:46:41 -0800 (PST)
David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the kernel command line interface is a f
On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
> We agree that, in the future, we'd like to provide the ability to
> dynamically allocate and free 1GB pages at runtime.
>
> Extending the kernel command line interface is a first step.
>
> Do you have a concrete objection to that first step ?
>
Yes
On Tue, Feb 18, 2014 at 02:16:42PM -0800, David Rientjes wrote:
> On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
>
> > > Lacking from your entire patchset is a specific example of what you want
> > > to do. So I think we're all guessing what exactly your usecase is and we
> > > aren't getting any
On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
> > Lacking from your entire patchset is a specific example of what you want
> > to do. So I think we're all guessing what exactly your usecase is and we
> > aren't getting any help. Are you really suggesting that a customer wants
> > to allocate 4
On Mon, Feb 17, 2014 at 03:23:16PM -0800, David Rientjes wrote:
> On Mon, 17 Feb 2014, Luiz Capitulino wrote:
>
> > hugepages= and hugepages_node= are similar, but have different semantics.
> >
> > hugepagesz= and hugepages= create a pool of huge pages of the specified
> > size.
> > This means t
On Sat, 2014-02-15 at 02:06 -0800, David Rientjes wrote:
> On Fri, 14 Feb 2014, Luiz Capitulino wrote:
>
> > > Again, I think this syntax is horrendous and doesn't couple well with the
> > > other hugepage-related kernel command line options. We already have
> > > hugepages= and hugepagesz= whi
On Mon, 17 Feb 2014, Luiz Capitulino wrote:
> hugepages= and hugepages_node= are similar, but have different semantics.
>
> hugepagesz= and hugepages= create a pool of huge pages of the specified size.
> This means that the number of times you specify those options are limited by
> the number of
On Sat, 15 Feb 2014 02:06:38 -0800 (PST)
David Rientjes wrote:
> On Fri, 14 Feb 2014, Luiz Capitulino wrote:
>
> > > Again, I think this syntax is horrendous and doesn't couple well with the
> > > other hugepage-related kernel command line options. We already have
> > > hugepages= and hugepag
On Fri, 14 Feb 2014, Luiz Capitulino wrote:
> > Again, I think this syntax is horrendous and doesn't couple well with the
> > other hugepage-related kernel command line options. We already have
> > hugepages= and hugepagesz= which you can interleave on the command line to
> > get 100 2M hugepa
On Fri, 14 Feb 2014 15:14:22 -0800 (PST)
David Rientjes wrote:
> On Thu, 13 Feb 2014, Luiz Capitulino wrote:
>
> > From: Luiz capitulino
> >
> > The HugeTLB command-line option hugepages= allows a user to specify how
> > many huge pages should be allocated at boot. This option is needed becaus
On Thu, 13 Feb 2014, Luiz Capitulino wrote:
> From: Luiz capitulino
>
> The HugeTLB command-line option hugepages= allows a user to specify how
> many huge pages should be allocated at boot. This option is needed because
> it improves reliability when allocating 1G huge pages, which are better
>
From: Luiz capitulino
The HugeTLB command-line option hugepages= allows a user to specify how
many huge pages should be allocated at boot. This option is needed because
it improves reliability when allocating 1G huge pages, which are better
allocated as early as possible due to fragmentation.
Ho
30 matches
Mail list logo
