All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, m.szyprowski@samsung.com,
	kyungmin.park@samsung.com, linux-mm@kvack.org
Subject: Re: [PATCH] Physical Memory Management [0/1]
Date: Fri, 15 May 2009 13:26:56 +0200	[thread overview]
Message-ID: <20090515112656.GD16682@one.firstfloor.org> (raw)
In-Reply-To: <op.utyv89ek7p4s8u@amdc030>

On Fri, May 15, 2009 at 12:47:23PM +0200, Michał Nazarewicz wrote:
> On Fri, 15 May 2009 12:18:11 +0200, Andi Kleen wrote:
> > That's not correct, support for multiple huge page sizes was recently
> > added. The interface is a bit clumpsy admittedly, but it's there.
> 
> I'll have to look into that further then.  Having said that, I cannot
> create a huge page SysV shared memory segment with pages of specified
> size, can I?

sysv shared memory supports huge pages, but there is currently
no interface to specify the intended page size, you always
get the default.

> 
> > However for non fragmentation purposes you probably don't
> > want too many different sizes anyways, the more sizes, the worse
> > the fragmentation. Ideal is only a single size.
> 
> Unfortunately, sizes may very from several KiBs to a few MiBs.

Then your approach will likely not be reliable.

> On the other hand, only a handful of apps will use PMM in our system
> and at most two or three will be run at the same time so hopefully
> fragmentation won't be so bad.  But yes, I admit it is a concern.

Such tight restrictions might work for you, but for mainline Linux the quality 
standards are higher.
 
> > As Peter et.al. explained earlier varying buffer sizes don't work
> > anyways.
> 
> Either I missed something or Peter and Adrew only pointed the problem
> we all seem to agree exists: a problem of fragmentation.

Multiple buffer sizes lead to fragmentation.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, m.szyprowski@samsung.com,
	kyungmin.park@samsung.com, linux-mm@kvack.org
Subject: Re: [PATCH] Physical Memory Management [0/1]
Date: Fri, 15 May 2009 13:26:56 +0200	[thread overview]
Message-ID: <20090515112656.GD16682@one.firstfloor.org> (raw)
In-Reply-To: <op.utyv89ek7p4s8u@amdc030>

On Fri, May 15, 2009 at 12:47:23PM +0200, MichaA? Nazarewicz wrote:
> On Fri, 15 May 2009 12:18:11 +0200, Andi Kleen wrote:
> > That's not correct, support for multiple huge page sizes was recently
> > added. The interface is a bit clumpsy admittedly, but it's there.
> 
> I'll have to look into that further then.  Having said that, I cannot
> create a huge page SysV shared memory segment with pages of specified
> size, can I?

sysv shared memory supports huge pages, but there is currently
no interface to specify the intended page size, you always
get the default.

> 
> > However for non fragmentation purposes you probably don't
> > want too many different sizes anyways, the more sizes, the worse
> > the fragmentation. Ideal is only a single size.
> 
> Unfortunately, sizes may very from several KiBs to a few MiBs.

Then your approach will likely not be reliable.

> On the other hand, only a handful of apps will use PMM in our system
> and at most two or three will be run at the same time so hopefully
> fragmentation won't be so bad.  But yes, I admit it is a concern.

Such tight restrictions might work for you, but for mainline Linux the quality 
standards are higher.
 
> > As Peter et.al. explained earlier varying buffer sizes don't work
> > anyways.
> 
> Either I missed something or Peter and Adrew only pointed the problem
> we all seem to agree exists: a problem of fragmentation.

Multiple buffer sizes lead to fragmentation.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

--
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:[~2009-05-15 11:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-13  9:26 [PATCH] Physical Memory Management [0/1] Michał Nazarewicz
2009-05-13  9:27 ` [PATCH] Physical Memory Management [1/1] Michał Nazarewicz
2009-05-13 22:11 ` [PATCH] Physical Memory Management [0/1] Andrew Morton
2009-05-13 22:11   ` Andrew Morton
2009-05-14  9:00   ` Michał Nazarewicz
2009-05-14  9:00     ` Michał Nazarewicz
2009-05-14 11:20     ` Peter Zijlstra
2009-05-14 11:20       ` Peter Zijlstra
2009-05-14 11:48       ` Michał Nazarewicz
2009-05-14 11:48         ` Michał Nazarewicz
2009-05-14 12:05         ` Peter Zijlstra
2009-05-14 12:05           ` Peter Zijlstra
2009-05-14 13:04           ` Michał Nazarewicz
2009-05-14 13:04             ` Michał Nazarewicz
2009-05-14 17:07             ` Andrew Morton
2009-05-14 17:07               ` Andrew Morton
2009-05-14 17:10               ` Peter Zijlstra
2009-05-14 17:10                 ` Peter Zijlstra
2009-05-15 10:06                 ` Michał Nazarewicz
2009-05-15 10:06                   ` Michał Nazarewicz
2009-05-15 10:18                   ` Andi Kleen
2009-05-15 10:18                     ` Andi Kleen
2009-05-15 10:47                     ` Michał Nazarewicz
2009-05-15 10:47                       ` Michał Nazarewicz
2009-05-15 11:03                       ` Peter Zijlstra
2009-05-15 11:03                         ` Peter Zijlstra
2009-05-15 11:11                         ` Michał Nazarewicz
2009-05-15 11:11                           ` Michał Nazarewicz
2009-05-15 11:26                       ` Andi Kleen [this message]
2009-05-15 11:26                         ` Andi Kleen
2009-05-15 12:05                         ` Michał Nazarewicz
2009-05-15 12:05                           ` Michał Nazarewicz
2009-05-14 19:33         ` Andi Kleen
2009-05-14 19:33           ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2009-05-13  9:23 Michał Nazarewicz

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=20090515112656.GD16682@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.nazarewicz@samsung.com \
    --cc=m.szyprowski@samsung.com \
    --cc=peterz@infradead.org \
    /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.