On Tue 03-04-18 18:56:27, Steven Rostedt wrote: [...] > From your earlier email: > > > Except that it doesn't work. si_mem_available is not really suitable for > > any allocation estimations. Its only purpose is to provide a very rough > > estimation for userspace. Any other use is basically abuse. The > > situation can change really quickly. Really it is really hard to be > > clever here with the volatility the memory allocations can cause. > > Now can you please explain to me why si_mem_available is not suitable > for my purpose. Several problems. It is overly optimistic especially when we are close to OOM. The available pagecache or slab reclaimable objects might be pinned long enough that your allocation based on that estimation will just make the situation worse and result in OOM. More importantly though, your allocations are GFP_KERNEL, right, that means that such an allocation will not reach to ZONE_MOVABLE or ZONE_HIGMEM (32b systems) while the pagecache will. So you will get an overestimate of how much you can allocate. Really si_mem_available is for proc/meminfo and a rough estimate of the free memory because users tend to be confused by seeing MemFree too low and complaining that the system has eaten all their memory. I have some skepticism about how useful it is in practice apart from showing it in top or alike tools. The memory is simply not usable immediately or without an overall and visible effect on the whole system. HTH -- Michal Hocko SUSE Labs
