On Thu, Feb 22, 2024 at 11:15:59PM +0000, Pedro Falcato wrote: > Hi, > > On Thu, Feb 22, 2024 at 8:35 AM Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > > > > Hello, Folk! > > > >[...] > > pagetable_alloc - gets increased as soon as a higher pressure is applied by > > increasing number of workers. Running same number of jobs on a next run > > does not increase it and stays on same level as on previous. > > > > /** > > * pagetable_alloc - Allocate pagetables > > * @gfp: GFP flags > > * @order: desired pagetable order > > * > > * pagetable_alloc allocates memory for page tables as well as a page table > > * descriptor to describe that memory. > > * > > * Return: The ptdesc describing the allocated page tables. > > */ > > static inline struct ptdesc *pagetable_alloc(gfp_t gfp, unsigned int order) > > { > > struct page *page = alloc_pages(gfp | __GFP_COMP, order); > > > > return page_ptdesc(page); > > } > > > > Could you please comment on it? Or do you have any thought? Is it expected? > > Is a page-table ever shrink? > > It's my understanding that the vunmap_range helpers don't actively > free page tables, they just clear PTEs. munmap does free them in > mmap.c:free_pgtables, maybe something could be worked up for vmalloc > too. > Right. I see that for a user space, pgtables are removed. There was a work on it. > > I would not be surprised if the memory increase you're seeing is more > or less correlated to the maximum vmalloc footprint throughout the > whole test. > Yes, the vmalloc footprint follows the memory usage. Some uses cases map lot of memory. Thanks for the input! -- Uladzislau Rezki