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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
