On Wed 25-10-17 00:30:18, Михаил Гаврилов wrote: > On 20 October 2017 at 14:12, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Fri 20-10-17 14:43:06, Du, Changbin wrote: > >> On Thu, Oct 19, 2017 at 11:52:49PM +0500, Михаил Гаврилов wrote: > >> > On 19 October 2017 at 08:56, Du, Changbin <changbin.du@xxxxxxxxx> wrote: > >> > > On Thu, Oct 19, 2017 at 01:16:48AM +0500, Михаил Гаврилов wrote: > >> > > I am curious about this, how can slub try to alloc compound page but the order > >> > > is 0? This is wrong. > >> > > >> > Nobody seems to know how this could happen. Can any logs shed light on this? > >> > > >> After checking the code, kernel can handle such case. So please ignore my last > >> comment. > >> > >> The warning is reporting OOM, first you need confirm if you have enough free > >> memory? If that is true, then it is not a programmer error. > > > > The kernel is not OOM. It just failed to allocate for GFP_NOWAIT which > > means that no memory reclaim could be used to free up potentially unused > > page cache. This means that kswapd is not able to free up memory in the > > pace it is allocated. Such an allocation failure shouldn't be critical > > and the caller should have means to fall back to a regular allocation or > > retry later. You can play with min_free_kbytes and increase it to kick > > the background reclaim sooner. > > Michal, thanks for clarification. > It means if any application allocate for GFP_NOWAIT and we not having > enough free memory (RAM) we will got this warning. > For example: > $ free -ht > total used free shared buff/cache available > Mem: 30G 27G 277M 1,6G 2,8G 593M > Swap: 59G 21G 38G > Total: 89G 48G 38G > I see that computer have total free 38G, but only 277M available free RAM. > So if we try allocate now more than 277M we get this warning again, right? Well, not really. As soon as we hit a so called low watermark the background reclaim (kswapd) kicks in and that will try to free up some of the reclaimable memory. Allocations are still allowed to go on. It is only when we hit min watermark when the allocation has to perform the memory reclaim in the allocation context (so called direct reclaim). GFP_NOWAIT request cannot sleep and as such they cannot perform the direct reclaim and have to fail. So this thing usually happens when the allocation pace is larger than the background reclaim can free up in the background. > I try reproduce it with kernel 4.13.8, but get another warning: > > [ 3551.169126] chrome: page allocation stalls for 11542ms, order:0, > mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null) this is a sleeping allocation which means that it is allowed to perform the direct reclaim and that took a lot of time here. This is really unusual and worth debugging some more. [...] > [ 3551.169590] Mem-Info: > [ 3551.169595] active_anon:6904352 inactive_anon:520427 isolated_anon:0 > active_file:55480 inactive_file:38890 isolated_file:0 > unevictable:1836 dirty:556 writeback:0 unstable:0 > slab_reclaimable:67559 slab_unreclaimable:95967 > mapped:353547 shmem:480723 pagetables:89161 bounce:0 > free:49404 free_pcp:1474 free_cma:0 This tells us that there is quite some page cache (file LRUs) to reclaim so I am wondering what could have caused such a delay. In order to debug this some more we would need an additional debugging information. I usually enable vmscan tracepoints to watch for events during the reclaim. [...] > it's same problem? so no, this looks like a separate issue. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
