Messages in this thread | | | Date | Tue, 2 Feb 2021 14:52:53 +0100 | From | Oscar Salvador <> | Subject | Re: [PATCH 2/2] x86/vmemmap: Handle unpopulated sub-pmd ranges |
| |
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@cn.fujitsu.com> 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
| |