Re: [PATCH 2/2] x86/vmemmap: Handle unpopulated sub-pmd ranges

[Oscar Salvador]

On Tue, Feb 02, 2021 at 02:29:11PM +0100, David Hildenbrand wrote:
> > @@ -1088,10 +1150,10 @@ remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
> >   				pages++;
> >   			} else {
> >   				/* If here, we are freeing vmemmap pages. */
> > -				memset((void *)addr, PAGE_INUSE, next - addr);
> > +				memset((void *)addr, PAGE_UNUSED, next - addr);
> >   				page_addr = page_address(pud_page(*pud));
> > -				if (!memchr_inv(page_addr, PAGE_INUSE,
> > +				if (!memchr_inv(page_addr, PAGE_UNUSED,
> >   						PUD_SIZE)) {
> >   					free_pagetable(pud_page(*pud),
> >   						       get_order(PUD_SIZE));
> 
> I'm sorry to bother you again, but isn't that dead code as well?

Heh, I spotted that earlier, but I did not think much of it honestly.

All this was introduced by:

 commit ae9aae9eda2db71bf4b592f15618b0160eb07731
 Author: Wen Congyang <wency@xxxxxxxxxxxxxx>
 Date:   Fri Feb 22 16:33:04 2013 -0800

     memory-hotplug: common APIs to support page tables hot-remove


> How do we ever end up using 1GB pages for the vmemmap? At least not via
> vmemmap_populate() - so I guess never? There are not many occurrences of
> "PUD_SIZE" in the file after all ...

AFAICT, we don't. The largest we populate for vmemmap is 2MB.
I see init_memory_mapping can use 1G, but that should not affect us.

I guess that the vmemmap handling for 1GB can go as well.
I will update the patchset.

-- 
Oscar Salvador
SUSE L3