On Thu, Jan 03, 2019 at 10:44:22AM +0100, Michal Hocko wrote: > On Sun 30-12-18 01:48:43, Kirill A. Shutemov wrote: > > On Sat, Dec 29, 2018 at 12:53:16PM -0800, Andrew Morton wrote: > > > > 1. use mmap() to allocate 4096 bytes for 1024*512 times (4096*1024*512=2G). > > > > 2. use madvise(MADV_DONTNEED) to free most of the above pages, but reserve a > > > > few pages(by if（i%33==0) continue;), then process's physical memory firstly > > > > come down, but after a few seconds, it rise back to 2G again, and can't come > > > > down forever. > > > > 3. if i delete this condition(if（i%33==0) continue;) or disable > > > > transparent_hugepage by setting 'enable' and 'defrag' to never, all go well and > > > > the physical memory can come down expectly. > > > > > > > > It seems like transparent_hugepage has problems with non-contiguous > > > > madvise(MADV_DONTEED). > > > > It's expected behaviour. > > > > MADV_DONTNEED doesn't guarantee that the range will not be repopulated > > (with or without direct action on application behalf). It's just a hint > > for the kernel. > > I agree with Kirill here but I would be interested in the underlying > usecase that triggered this. The test case is clearly artificial but is > any userspace actually relying on MADV_DONTNEED reducing the rss > longterm? > > > For sparse mappings, consider using MADV_NOHUGEPAGE. Should the MADV_DONTNEED hint imply MADV_NOHUGEPAGE? It'd prevent coalescing elsewhere in the VMA, so that might negatively affect other programs.
