Hi Dave
I cannot catch what is done by codes below .
--
static unsigned long sparse_encode_mem_map(struct page *mem_map, int pnum)
{
return (unsigned long)(mem_map - (pnum << PFN_SECTION_SHIFT));
}
static struct page *sparse_decode_mem_map(unsigned long coded_mem_map,
int pnum)
{
return ((struct page *)coded_mem_map) + (pnum << PFN_SECTION_SHIFT);
}
<snip>
ms->section_mem_map |= sparse_encode_mem_map(mem_map, pnum);
<snip>
static inline struct page *__section_mem_map_addr(struct mem_section
*section)
{
unsigned long map = section->section_mem_map;
map &= SECTION_MAP_MASK;
return (struct page *)map;
}
--
How does this encoding work ?
_section_mem_map_addr() can return valid address ?
-- Kame <kamezawa.hiroyu@xxxxxxxxxxxxxx>
Dave Hansen wrote:
>I think it's time to start settling these down a bit, and think about
>getting the sparse changes into -mm.
>
>It should now be a bit harder to get section onlining failures because
>of a lack of contiguous lowmem:
>
>http://sr71.net/patches/2.6.11/2.6.11-rc2-mm2-mhp1/broken-out/B-sparse-153-sparse-bits.patch
>
>basically enables us to keep mem_map around for non-existent sections,
>and to steal those unused mem_maps for other sections. This, combined
>with now using vmalloc() when kmalloc() fails should make it quite a bit
>more reliable.
>
>- x86_64 patch has been merged
>- early_printk and page_is_ram_e820() should be out of the way now
>- rollups do not contain early_print.patch or Z2-debug.patch, but
> are still in the series file and the "broken-out" tarball.
>- patch to keep new pipe code from using highmem
>- now completes 'sh run.sh 5 ./aioalloc;' test
>- more KERN_* levels added to printk()s. dmesg should be quieter now
>
>-- Dave
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>Lhms-devel mailing list
>Lhms-devel@xxxxxxxxxxxxxxxxxxxxx
>https://lists.sourceforge.net/lists/listinfo/lhms-devel
>
>
>
