From: Mel Gorman <mel@csn.ul.ie>
To: Yasunori Goto <ygoto@us.fujitsu.com>
Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Avoiding fragmentation through different allocator
Date: Sun, 16 Jan 2005 16:21:17 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.58.0501161613350.16492@skynet> (raw)
In-Reply-To: <20050115172317.3C0F.YGOTO@us.fujitsu.com>
On Sat, 15 Jan 2005, Yasunori Goto wrote:
> There are 2 types of memory hotplug.
>
> a)SMP machine case
> A some part of memory will be added and removed.
>
> b)NUMA machine case.
> Whole of a node will be able to remove and add.
> However, if a block of memory like DIMM is broken and disabled,
> Its close from a).
>
> How to know where is hotpluggable bank is platform/archtecture
> dependent issue.
> ex) Asking to ACPI.
> Just node0 become unremovable, and other nodes are removable.
> etc...
>
Is there an architecture-independant way of finding this out?
> In current your patch, first attribute of all pages are NoRclm.
> But if your patches has interface to decide where will be Rclm for
> each arch/platform, it might be good.
>
It doesn't have an API as such. In page_alloc.c, there is a function
get_pageblock_type() that returns what type of allocation the block of
memory is being used for. There is no guarentee there is only those type
of allocations there though.
>
> > The danger is
> > that allocations would fail because non-hotplug banks were already full
> > and pageout would not happen because the watermarks were satisified.
>
> In this case, if user can change attribute Rclm area to
> NoRclm, it is better than nothing.
> In hotplug patches, there will be new zone as ZONE_REMOVABLE.
What's the current attidute for adding a new zone? I felt there would be
resistence as a new zone would affect a lot of code paths and be yet
another zone that needed balancing. For example, is there a HIGHMEM
version of the ZONE_REMOVABLE or could normal and highmem be in this zone?
> But in this patch, this change attribute is a little bit difficult.
> (At first remove the pages from free_area of removable zone,
> then add them to free_area of Un-removable zone.)
> Probably its change is easier in your patch.
>
I think the difficulty would be similar because it's still Move Pages From
A To B.
> I agree that dividing per-cpu caches is not good way.
> But if Kernel-nonreclaimable allocation use its UserRclm pool,
> its removable memory bank will be harder to remove suddenly.
> Is it correct? If so, it is not good for memory hotplug.
> Hmmmm.
>
It is correct. However, this will only happen in low-memory conditions.
For a kernel-nonreclaimable allocation to use the userrclm pool, three
conditions have to be met;
1. Kernel-nonreclaimable pool has no pages
2. There are no global 2^MAX_ORDER pages
3. Kern-reclaimable pool has no pages
This is because of the fallback order. If you were interested in testing a
particular workload, you could apply the patch, run a workload and then
look at /proc/buddyinfo. There are three counters at the end of the
output like this;
KernNoRclm Fallback count: 0
KernRclm Fallback count: 0
UserRclm Fallback count: 425
A fallback can get counted twice. For example, if KernNoRclm falls back to
KernRclm and then UserRclm, it's considered to be two fallbacks.
I also have (yet another) tool that is able to track exactly where each
type of allocation is. If you wanted to know precisely where each page is
and see how many non-reclaimable pages are ending up in the wrong place,
the tool could be modified to do that.
--
Mel Gorman
next prev parent reply other threads:[~2005-01-16 16:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-12 22:45 [RFC] Avoiding fragmentation through different allocator Tolentino, Matthew E
2005-01-12 23:12 ` Mel Gorman
2005-01-13 8:02 ` Hirokazu Takahashi
2005-01-13 10:27 ` Mel Gorman
2005-01-16 4:03 ` Yasunori Goto
2005-01-16 16:21 ` Mel Gorman [this message]
2005-01-17 23:08 ` Yasunori Goto
2005-01-19 13:45 ` Mel Gorman
-- strict thread matches above, loose matches on Subject: below --
2005-01-17 16:48 Tolentino, Matthew E
2005-01-19 13:17 ` Mel Gorman
2005-01-12 21:09 Mel Gorman
2005-01-13 7:03 ` Matt Mackall
2005-01-13 7:20 ` Trond Myklebust
2005-01-13 10:22 ` Mel Gorman
2005-01-13 7:31 ` William Lee Irwin III
2005-01-13 10:11 ` Mel Gorman
2005-01-14 21:42 ` Marcelo Tosatti
2005-01-15 1:31 ` William Lee Irwin III
2005-01-15 19:19 ` Mel Gorman
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=Pine.LNX.4.58.0501161613350.16492@skynet \
--to=mel@csn.ul.ie \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.e.tolentino@intel.com \
--cc=ygoto@us.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).