On Fri, Feb 16, 2018 at 10:08:28AM -0600, Christopher Lameter wrote:
> On Fri, 16 Feb 2018, Matthew Wilcox wrote:
> > I don't understand this response. I'm not suggesting mixing objects
> > of different sizes within the same page. The vast majority of slabs
> > use order-0 pages, a few use order-
On Fri, 16 Feb 2018, Matthew Wilcox wrote:
> On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote:
> > On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > > What I was proposing was an intermediate page allocator where slab would
> > > request 2MB for its own uses all at once, then alloc
On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote:
> On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > What I was proposing was an intermediate page allocator where slab would
> > request 2MB for its own uses all at once, then allocate pages from that to
> > individual slabs, so allo
On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > The inducing of releasing memory back is not there but you can run SLUB
> > with MAX_ORDER allocations by passing "slab_min_order=9" or so on bootup.
>
> This is subtly different from the idea that I had. If you set
> slub_min_order to 9, then slub w
On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> On Thu, Feb 15, 2018 at 09:49:00AM -0600, Christopher Lameter wrote:
> > On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> >
> > > What if ... on startup, slab allocated a MAX_ORDER page for itself.
> > > It would then satisfy its own page allocation request
On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> What I was proposing was an intermediate page allocator where slab would
> request 2MB for its own uses all at once, then allocate pages from that to
> individual slabs, so allocating a kmalloc-32 object and a dentry object
> would result in 510 pages o
On Thu, Feb 15, 2018 at 09:49:00AM -0600, Christopher Lameter wrote:
> On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > What if ... on startup, slab allocated a MAX_ORDER page for itself.
> > It would then satisfy its own page allocation requests from this giant
> > page. If we start to run low on m
On Thu, 15 Feb 2018, Michal Hocko wrote:
> > When the amount of kernel
> > memory is well bounded for certain systems, it is better to aggressively
> > reclaim from existing MIGRATE_UNMOVABLE pageblocks rather than eagerly
> > fallback to others.
> >
> > We have additional patches that help wi
On Thu, Feb 15, 2018 at 09:49:00AM -0600, Christopher Lameter wrote:
> On Thu, 15 Feb 2018, Matthew Wilcox wrote:
>
> > What if ... on startup, slab allocated a MAX_ORDER page for itself.
> > It would then satisfy its own page allocation requests from this giant
> > page. If we start to run low o
On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> What if ... on startup, slab allocated a MAX_ORDER page for itself.
> It would then satisfy its own page allocation requests from this giant
> page. If we start to run low on memory in the rest of the system, slab
> can be induced to return some of it
On Thu, Feb 15, 2018 at 03:45:25PM +0100, Michal Hocko wrote:
> > When the amount of kernel
> > memory is well bounded for certain systems, it is better to aggressively
> > reclaim from existing MIGRATE_UNMOVABLE pageblocks rather than eagerly
> > fallback to others.
> >
> > We have additional
On Wed 14-02-18 02:28:38, David Rientjes wrote:
> On Wed, 14 Feb 2018, Michal Hocko wrote:
>
> > I do not have any objections regarding the extension. What I am more
> > interested in is _why_ people are still using this command line
> > parameter at all these days. Why would anybody want to intro
On Wed, 14 Feb 2018, Michal Hocko wrote:
> I do not have any objections regarding the extension. What I am more
> interested in is _why_ people are still using this command line
> parameter at all these days. Why would anybody want to introduce lowmem
> issues from 32b days. I can see the CMA/Hotp
On Mon 12-02-18 16:24:25, David Rientjes wrote:
> Both kernelcore= and movablecore= can be used to define the amount of
> ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires
> the system memory capacity to be known when specifying the command line,
> however.
>
> This introduces
On Tue, 13 Feb 2018 15:55:11 -0800 (PST) David Rientjes
wrote:
> >
> > Is this fine-grained enough? We've had percentage-based tunables in
> > the past, and 10 years later when systems are vastly larger, 1% is too
> > much.
> >
>
> They still have the (current) ability to define the exact am
On Tue, 13 Feb 2018, Mike Kravetz wrote:
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -1825,30 +1825
On 02/12/2018 04:24 PM, David Rientjes wrote:
> Both kernelcore= and movablecore= can be used to define the amount of
> ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires
> the system memory capacity to be known when specifying the command line,
> however.
>
> This introduces t
On Tue, 13 Feb 2018, Andrew Morton wrote:
> > Both kernelcore= and movablecore= can be used to define the amount of
> > ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires
> > the system memory capacity to be known when specifying the command line,
> > however.
> >
> > This int
On Mon, 12 Feb 2018 16:24:25 -0800 (PST) David Rientjes
wrote:
> Both kernelcore= and movablecore= can be used to define the amount of
> ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires
> the system memory capacity to be known when specifying the command line,
> however.
>
Both kernelcore= and movablecore= can be used to define the amount of
ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires
the system memory capacity to be known when specifying the command line,
however.
This introduces the ability to define both kernelcore= and movablecore=
as
20 matches
Mail list logo
