From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Joel Schopp <jschopp@austin.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
lhms-devel@lists.sourceforge.net
Subject: Re: [Lhms-devel] Re: [PATCH 0/5] Reducing fragmentation using zones
Date: Fri, 20 Jan 2006 19:40:39 +0900 [thread overview]
Message-ID: <43D0BE27.5000807@jp.fujitsu.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0601200934300.10920@skynet>
Mel Gorman wrote:>
> What sort of tests would you suggest?
> The tests I have been running to date are
>
> "kbuild + aim9" for regression testing
>
> "updatedb + 7 -j1 kernel compiles + highorder allocation" for seeing how
> easy it was to reclaim contiguous blocks
>
> What tests could be run that would be representative of real-world
> workloads?
>
1. Using 1000+ processes(threads) at once
2. heavy network load.
3. running NFS
is maybe good.
>>>> And, for people who want to remove range of memory, list-based approach
>>>> will
>>>> need some other hook and its flexibility is of no use.
>>>> (If list-based approach goes, I or someone will do.)
>>>>
>>> Will do what?
>>>
>> add kernelcore= boot option and so on :)
>> As you say, "In an ideal world, we would have both".
>>
>
> List-based was frowned at for adding complexity to the main path so we may
> not get list-based built on top of zone based even though it is certinatly
> possible. One reason to do zone-based was to do a comparison between them
> in terms of complexity. Hopefully, Nick Piggin (as the first big objector
> to the list-based approach) will make some sort of comment on what he
> thinks of zone-based in comparison to list-based.
>
I think there is another point.
what I concern about is Linus's word ,this:
> My point is that regardless of what you _want_, defragmentation is
> _useless_. It's useless simply because for big areas it is so expensive as
> to be impractical.
You should make your own answer for this before posting.
From the old threads (very long!), I think one of the point was :
To use hugepages, sysadmin can specifies what he wants at boot time.
This guarantees 100% allocation of needed huge pages.
Why memhotplug cannot specifies "how much they can remove" before booting.
This will guaranntee 100% memory hotremove.
I think hugetlb and memory hotplug cannot be good reason for defragment.
Finding the reason for defragment is good.
Unfortunately, I don't know the cases of memory allocation failure
because of fragmentation with recent kernel.
-- Kame
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Joel Schopp <jschopp@austin.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
lhms-devel@lists.sourceforge.net
Subject: Re: [Lhms-devel] Re: [PATCH 0/5] Reducing fragmentation using zones
Date: Fri, 20 Jan 2006 19:40:39 +0900 [thread overview]
Message-ID: <43D0BE27.5000807@jp.fujitsu.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0601200934300.10920@skynet>
Mel Gorman wrote:>
> What sort of tests would you suggest?
> The tests I have been running to date are
>
> "kbuild + aim9" for regression testing
>
> "updatedb + 7 -j1 kernel compiles + highorder allocation" for seeing how
> easy it was to reclaim contiguous blocks
>
> What tests could be run that would be representative of real-world
> workloads?
>
1. Using 1000+ processes(threads) at once
2. heavy network load.
3. running NFS
is maybe good.
>>>> And, for people who want to remove range of memory, list-based approach
>>>> will
>>>> need some other hook and its flexibility is of no use.
>>>> (If list-based approach goes, I or someone will do.)
>>>>
>>> Will do what?
>>>
>> add kernelcore= boot option and so on :)
>> As you say, "In an ideal world, we would have both".
>>
>
> List-based was frowned at for adding complexity to the main path so we may
> not get list-based built on top of zone based even though it is certinatly
> possible. One reason to do zone-based was to do a comparison between them
> in terms of complexity. Hopefully, Nick Piggin (as the first big objector
> to the list-based approach) will make some sort of comment on what he
> thinks of zone-based in comparison to list-based.
>
I think there is another point.
what I concern about is Linus's word ,this:
> My point is that regardless of what you _want_, defragmentation is
> _useless_. It's useless simply because for big areas it is so expensive as
> to be impractical.
You should make your own answer for this before posting.
From the old threads (very long!), I think one of the point was :
To use hugepages, sysadmin can specifies what he wants at boot time.
This guarantees 100% allocation of needed huge pages.
Why memhotplug cannot specifies "how much they can remove" before booting.
This will guaranntee 100% memory hotremove.
I think hugetlb and memory hotplug cannot be good reason for defragment.
Finding the reason for defragment is good.
Unfortunately, I don't know the cases of memory allocation failure
because of fragmentation with recent kernel.
-- Kame
--
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:[~2006-01-20 10:41 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 19:08 [PATCH 0/5] Reducing fragmentation using zones Mel Gorman
2006-01-19 19:08 ` Mel Gorman
2006-01-19 19:08 ` [PATCH 1/5] Add __GFP_EASYRCLM flag and update callers Mel Gorman
2006-01-19 19:08 ` Mel Gorman
2006-01-19 19:08 ` [PATCH 2/5] Create the ZONE_EASYRCLM zone Mel Gorman
2006-01-19 19:08 ` Mel Gorman
2006-01-19 19:09 ` [PATCH 3/5] x86 - Specify amount of kernel memory at boot time Mel Gorman
2006-01-19 19:09 ` Mel Gorman
2006-01-19 19:09 ` [PATCH 4/5] ppc64 " Mel Gorman
2006-01-19 19:09 ` Mel Gorman
2006-01-19 19:09 ` [PATCH 5/5] ForTesting - Prevent OOM killer firing for high-order allocations Mel Gorman
2006-01-19 19:09 ` Mel Gorman
2006-01-19 19:24 ` [PATCH 0/5] Reducing fragmentation using zones Joel Schopp
2006-01-19 19:24 ` Joel Schopp
2006-01-20 0:13 ` [Lhms-devel] " KAMEZAWA Hiroyuki
2006-01-20 0:13 ` KAMEZAWA Hiroyuki
2006-01-20 1:09 ` Mel Gorman
2006-01-20 1:09 ` Mel Gorman
2006-01-20 1:25 ` KAMEZAWA Hiroyuki
2006-01-20 1:25 ` KAMEZAWA Hiroyuki
2006-01-20 9:44 ` Mel Gorman
2006-01-20 9:44 ` Mel Gorman
2006-01-20 10:40 ` KAMEZAWA Hiroyuki [this message]
2006-01-20 10:40 ` KAMEZAWA Hiroyuki
2006-01-20 14:53 ` Mel Gorman
2006-01-20 18:10 ` Kamezawa Hiroyuki
2006-01-20 18:10 ` Kamezawa Hiroyuki
2006-01-20 12:08 ` Yasunori Goto
2006-01-20 12:08 ` Yasunori Goto
2006-01-20 12:25 ` Mel Gorman
2006-01-20 12:25 ` Mel Gorman
2006-01-20 13:22 ` Yasunori Goto
2006-01-20 13:22 ` Yasunori Goto
2006-01-20 0:42 ` Mel Gorman
2006-01-20 0:42 ` Mel Gorman
2006-01-20 1:18 ` KAMEZAWA Hiroyuki
2006-01-20 1:18 ` KAMEZAWA Hiroyuki
2006-01-20 12:03 ` Mel Gorman
2006-01-20 12:03 ` Mel Gorman
2006-01-20 13:28 ` [Lhms-devel] " Yasunori Goto
2006-01-20 13:28 ` Yasunori Goto
2006-01-20 14:02 ` Mel Gorman
2006-01-20 14:02 ` 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=43D0BE27.5000807@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=jschopp@austin.ibm.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/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.