On Fri, May 03, 2019 at 11:16:34PM +0200, Markus Gothe wrote: > Err, zram ofc :) ... > > Or even better you could turn on zswap on your embedded device and avoid the > OOM-kiler which I guess is the real reason you fixed this.
Actually RAM was not the problem at all. It really was the time to spawn all the processes and the overhead to serialize them. > Actually I want to know when this happens that the kernel creates that many > hotplug events; seems like the issue is somewhere else. We're building an IVI (In Vehicle Infotainment) system that needs to boot really fast. For example we have to show a rear view camera in 2s from cold boot. To achive this the kernel is kept very small and most of the drivers are loaded as modules when they are actually needed. This alone creates so many events that the impact is measurable. Regards, Jan > > //M > > Sent from my BlackBerry — the most secure mobile device > > > Original Message > > > > From: j...@kloetzke.net > Sent: 3 May 2019 23:03 > To: busybox@busybox.net > Subject: [PATCH 0/3] mdev: add daemon mode > > > If mdev is used as kernel hotplug helper and the system generates many > hotplug events it will quickly consume considerable resources because a > process is forked for each event and, if the mdev.seq feature is used, > they must also coordinate among each other. While the uevent applet > mitigates some of the resource problems you still have to pay the cost > for a fork/exec and parsing of mdev.conf for each event. > > The following patches add an optional daemon mode to mdev that let's > mdev listen on a netlink socket for kernel hotplug events. This mode > works much like udev and avoids the fork/exec/parse overhead on many > events. > > > _______________________________________________ > busybox mailing list > busybox@busybox.net > http://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
