Messages in this thread | | | Date | Wed, 15 Dec 2010 09:21:34 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: PROBLEM: __offline_isolated_pages may offline too many pages |
| |
On Tue, 14 Dec 2010 16:01:39 +0100 Ingo Korb <ingo@akana.de> wrote:
> Hi! > > [1.] One line summary of the problem: > __offline_isolated_pages may isolate too many pages > > [2.] Full description of the problem/report: > While experimenting with remove_memory/online_pages, removing as few > pages as possible (pageblock_nr_pages, 512 on my box) I noticed that the > number of pages marked "reserved" increased even though both functions > did not indicate an error. Following the code it was clear that > __offline_isolated_pages marked twice as many pages as it should: >
It's designed for offline memory section > MAX_ORDER. pageblock_nr_pages is tend to be smaller than that.
Do you see the problem with _exsisting_ user interface of memory hotplug ? I think we have no control other than memory section.
> === start paste (from dmesg) === > Offlined Pages 512 > remove from free list c00 1024 e00 > === end paste === > > The issue seems to be that __offline_isolated_pages blindly uses > page_order() to determine how many pages it should mark as reserved in > the current loop iteration, without checking if this would exceed the > limit set by end_pfn. >
It's because designed to work under memory section, it's aligned to MAX_ORDER. Its blindness works correctly.
> I'm not sure what the correct way to fix this would be - is memory > isolation supposed to touch the order of a page if it crosses the end > (or beginning!) of the range of pages to be isolated? >
Nothing to be fixed. If you _need_ another functionality, please add a new feature. But, in theory, memory offline doesn't work in the range smaller than MAX_ORDER because of buddy allocator.
Thanks, -Kame
| |