lkml.org 
[lkml]   [2008]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Re: [PATCH]Fix usemap for DISCONTIG/FLATMEM with not-aligned zone initilaization.
Thank you for looking into.

>> - if ((pfn & (pageblock_nr_pages-1)))
>> - set_pageblock_migratetype(page, MIGRATE_MOVABLE);
>> + set_pageblock_migratetype(page, MIGRATE_MOVABLE);
>>
>
>The point of the if there was so that set_pageblock_migratetype() would
>only be called once per pageblock. The impact with an unaligned zone is
>that the first block is not set and will be used for UNMOVABLE pages
>initially. However, this is not a major impact and there is no need to
>call set_pageblock_migratetype for every page.
>
But if ((pfn & (pageblock_nr_pages -1))) is not correct.
for calling set_pageblock_migrationtype() once in a pageblock,
!((pfn & (pageblock_nr_pages -1))) is correct.


>
>This is a pretty large change for what seems to be a fairly basic problem -
I think so ;(

>alignment issues during boot where I'm guessing we are writing past the end
>of the bitmap. Even if the virtual memmap is covering non-existant pages,
>the PFNs there for bitmaps and the like should still not be getting used
>and the map size is already rounded up to the pageblock size. It's also
>expanding the size of zone which seems overkill.
>
>I think I have a possible alternative fix below.
>
ok.

>What about something like the following? Instead of expanding the size of
>structures, it sanity checks input parameters. It touches a number of places
>because of an API change but it is otherwise straight-forward.
>
>Unfortunately, I do not have an IA-64 machine that can reproduce the problem
>to see if this still fixes it or not so a test as well as a review would be
>appreciated. What should happen is the machine boots but prints a warning
>about the unexpected PFN ranges. It boot-tested fine on a number of other
>machines (x86-32 x86-64 and ppc64).
>
ok, I'll test today if I have a chance. At least, I think I can test this
until Monday. but I have one concern (below)


>+ /*
>+ * Sanity check the values passed in. It is possible an architecture
>+ * calling this function directly will use values outside of the memory
>+ * they registered
>+ */
>+ if (start_pfn < zone->zone_start_pfn) {
>+ WARN_ON_ONCE(1);
>+ start_pfn = zone->zone_start_pfn;
>+ }
>+
>+ if (size > zone->spanned_pages) {
>+ WARN_ON_ONCE(1);
>+ size = zone->spanned_pages;
>+ }
>
My concern here is, memmap out-of-zone is not initialized and not
marked as PG_reserved...sholdn't we initialize existing memmap even
if they are out-ot-zone ? I think all existing mem_map for memory hole
should be initialized properly.

Thanks,
-Kame



\
 
 \ /
  Last update: 2008-04-18 19:39    [W:0.876 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site