[PATCH 2/8] mdev: increase netlink buffer sizes

Jan Klötzke jan at kloetzke.net
Thu Dec 19 20:20:33 UTC 2019


On Wed, Dec 18, 2019 at 09:34:39PM +0100, Bernhard Reutner-Fischer wrote:
> On 17 December 2019 17:06:46 CET, "Jan Klötzke" <jan at kloetzke.net> wrote:
> >On Tue, Dec 17, 2019 at 12:01:09AM +0000, Laurent Bercot wrote:
> >> 
> >> > The socket receive buffer turned out to be too small for real world
> >> > systems. Use the same size as udevd to be on the safe side. As this
> >is
> >> > just a limit and the memory is not allocated by the kernel until
> >really
> >> > needed there is actually no memory wasted.
> >> 
> >> Is it also the case when overcommit is disabled?
> >> busybox is used in a lot of embedded systems, and some of them
> >disable
> >> overcommit. Committing 128 MiB would make mdev completely unusable.
> >
> >AFAICT it is not accounted to the process memory until the data is
> >actually queued on the socket.
> 
> So can you check if booting with mem=6M or the like works when
> receiving lots of messages and overcommit disabled please?

I've booted a qemu system with 32M RAM. Linux would not boot if I used less RAM...

/ # free -m
              total        used        free      shared  buff/cache   available
Mem:             21          11           4           0           5           7
Swap:             0           0           0

Overcommit is disabled:

/ # cat /proc/sys/vm/overcommit_memory 
2

Then start mdev in daemon mode. It's running and the free memory has not changed:

/ # mdev -dfv
...
^Z[1]+  Stopped                    mdev -dfv
/ # free -m
              total        used        free      shared  buff/cache   available
Mem:             21          11           4           0           5           7
Swap:             0           0           0

Lets provoke an OOM by keeping mdev stopped and by generating uvents:

/ # find /sys -name uevent | while read -r i ; do echo add >$i ; done
/ # find /sys -name uevent | while read -r i ; do echo add >$i ; done
... repeat ...
/ # find /sys -name uevent | while read -r i ; do echo add >$i ; done
find invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
CPU: 0 PID: 397 Comm: find Not tainted 5.3.9 #1
Hardware name: ARM-Versatile Express
[<80110980>] (unwind_backtrace) from [<8010c5ec>] (show_stack+0x10/0x14)
[<8010c5ec>] (show_stack) from [<807522c4>] (dump_stack+0x84/0x98)
[<807522c4>] (dump_stack) from [<801fe03c>] (dump_header+0x54/0x264)
[<801fe03c>] (dump_header) from [<801fd484>] (oom_kill_process+0x328/0x338)
[<801fd484>] (oom_kill_process) from [<801fdc68>] (out_of_memory+0xe8/0x3f4)
[<801fdc68>] (out_of_memory) from [<8023dbf8>] (__alloc_pages_nodemask+0xf9c/0x10dc)
[<8023dbf8>] (__alloc_pages_nodemask) from [<802294c4>] (handle_mm_fault+0x3fc/0xa24)
[<802294c4>] (handle_mm_fault) from [<80114a2c>] (do_page_fault+0x114/0x38c)
[<80114a2c>] (do_page_fault) from [<80114e0c>] (do_DataAbort+0x3c/0xc0)
[<80114e0c>] (do_DataAbort) from [<80101ddc>] (__dabt_usr+0x3c/0x40)
...
Tasks state (memory values in pages):
[  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[     74]     0    74      823       28     8192        0             0 sh
[    368]     0   368      823       24     8192        0             0 mdev
[    397]     0   397      850      106     8192        0             0 find
[    398]     0   398      823       94     8192        0             0 sh
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,task=find,pid=397,uid=0
Out of memory: Killed process 397 (find) total-vm:3400kB, anon-rss:120kB, file-rss:304kB, shmem-rss:0kB
oom_reaper: reaped process 397 (find), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Killed
/ # free
              total        used        free      shared  buff/cache   available
Mem:          22228       14476        1468           0        6284        5404
Swap:             0           0           0

Resuming mdev yields a ton of events as expected...

So the socket is not counted as committed memory but as the events pile
up they will add to the memory pressure...

/Jan


More information about the busybox mailing list