Hi Steve, On Fri, Mar 30, 2018 at 12:10 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: [..] >> > I wonder if I should have the ring buffer allocate groups of pages, to >> > avoid this. Or try to allocate with NORETRY, one page at a time, and >> > when that fails, allocate groups of pages with RETRY_MAYFAIL, and that >> > may keep it from causing an OOM? >> > >> >> I don't see immediately how that can prevent an OOM in other >> applications here? If ftrace allocates lots of memory with >> RETRY_MAYFAIL, then we would still OOM in other applications if memory >> isn't available. Sorry if I missed something. > > Here's the idea. > > Allocate one page at a time with NORETRY. If that fails, then allocate > larger amounts (higher order of pages) with RETRY_MAYFAIL. Then if it > can't get all the memory it needs, it wont take up all memory in the > system before it finds out that it can't have any more. > > Or perhaps the memory management system can provide a > get_available_mem() function that ftrace could call before it tries to > increase the ring buffer and take up all the memory of the system > before it realizes that it can't get all the memory it wants. > > The main problem I have with Zhaoyang's patch is that > get_available_mem() does not belong in the tracing code. It should be > something that the mm subsystem provides. > Cool. Personally I like the getting of available memory solution and use that, since its simpler. MM already provides it through si_mem_available since the commit "mm/page_alloc.c: calculate 'available' memory in a separate function" (sha d02bd27b). Maybe we could just use that? MemAvailable was initially added in commit "/proc/meminfo: provide estimated available memory" (sha 34e431b0ae39) thanks, - Joel
