From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: 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 12:47:23 +0200 [thread overview]
Message-ID: <op.utyv89ek7p4s8u@amdc030> (raw)
In-Reply-To: <20090515101811.GC16682@one.firstfloor.org>
>> Correct me if I'm wrong, but if I understand correctly, currently only
>> one size of huge page may be defined, even if underlaying architecture
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?
> 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.
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.
>> largest blocks that may ever be requested and then waste a lot of
>> memory when small pages are requested or (ii) define smaller huge
>> page size but then special handling of large regions need to be
>> implemented.
>
> If you don't do that then long term fragmentation will
> kill you anyways. it's easy to show that pre allocation with lots
> of different sizes is about equivalent what the main page allocator
> does anyways.
However, having an allocator in PMM used by a handful of apps, an
architect may provide a use cases that need to be supported and then
PMM may be reimplemented to guarantee that those cases are handled.
> 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.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, MichaA? "mina86" Nazarewicz (o o)
ooo +-<m.nazarewicz@samsung.com>-<mina86@jabber.org>-ooO--(_)--Ooo--
--
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:[~2009-05-15 10:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <op.utu26hq77p4s8u@amdc030>
2009-05-13 22:11 ` Andrew Morton
2009-05-14 9:00 ` Michał Nazarewicz
2009-05-14 11:20 ` Peter Zijlstra
2009-05-14 11:48 ` Michał Nazarewicz
2009-05-14 12:05 ` Peter Zijlstra
2009-05-14 13:04 ` Michał Nazarewicz
2009-05-14 17:07 ` Andrew Morton
2009-05-14 17:10 ` Peter Zijlstra
2009-05-15 10:06 ` Michał Nazarewicz
2009-05-15 10:18 ` Andi Kleen
2009-05-15 10:47 ` Michał Nazarewicz [this message]
2009-05-15 11:03 ` Peter Zijlstra
2009-05-15 11:11 ` Michał Nazarewicz
2009-05-15 11:26 ` Andi Kleen
2009-05-15 12:05 ` Michał Nazarewicz
2009-05-14 19:33 ` Andi Kleen
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=op.utyv89ek7p4s8u@amdc030 \
--to=m.nazarewicz@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox