Re: [PATCH] net/skbuff: silence warnings under memory pressure

On Tue, 2019-09-03 at 20:53 +0200, Michal Hocko wrote:

quoted

On Tue 03-09-19 11:42:22, Qian Cai wrote:

quoted

On Tue, 2019-09-03 at 15:22 +0200, Michal Hocko wrote:

quoted

On Fri 30-08-19 18:15:22, Eric Dumazet wrote:

quoted

If there is a risk of flooding the syslog, we should fix this
generically
in mm layer, not adding hundred of __GFP_NOWARN all over the places.

We do already ratelimit in warn_alloc. If it isn't sufficient then we
can think of a different parameters. Or maybe it is the ratelimiting
which doesn't work here. Hard to tell and something to explore.

The time-based ratelimit won't work for skb_build() as when a system under
memory pressure, and the CPU is fast and IO is so slow, it could take a long
time to swap and trigger OOM.

I really do not understand what does OOM and swapping have to do with
the ratelimiting here. The sole purpose of the ratelimit is to reduce
the amount of warnings to be printed. Slow IO might have an effect on
when the OOM killer is invoked but atomic allocations are not directly
dependent on IO.

When there is a heavy memory pressure, the system is trying hard to reclaim
memory to fill up the watermark. However, the IO is slow to page out, but the
memory pressure keep draining atomic reservoir, and some of those skb_build()
will fail eventually.

Yes this is true but this has nothing to do with the ratelimitted
warn_alloc AFAICS. It is natural that atomic allocations are going
to fail more likely under extreme memory pressure but we are talking
about an excessive amount of debugging output that is generated and
that should be throttled. And that's why we have ratelimit there. If it
doesn't work well then we should look into why.

Only if there is a fast IO, it will finish swapping sooner and then invoke the
OOM to end the memory pressure.

-- 
Michal Hocko
SUSE Labs