Ouch, then fork()'ing is indeed an issue. And Linux not being an RTOS is
another issue, but I hope you are using an RTOS (like QNX or FreeRTOS) and not
Linux.
As pointed out the whole Linux hotplugging system is the real issue here and
something like mdevd would be the answer.
//M
Sent from
On Sat, May 04, 2019 at 07:42:06AM +, Laurent Bercot wrote:
>
> > 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,
> >
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
On Sat, May 04, 2019 at 08:06:44AM +0200, Peter Korsgaard wrote:
> > "Jan" == Jan Klötzke writes:
>
> > Adds the -s option to run mdev in daemon mode handling hotplug events
> > from the kernel like udev. If the system generates many hotplug events
> > this mode of operation will consume
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
> "Jan" == Jan Klötzke writes:
> Adds the -s option to run mdev in daemon mode handling hotplug events
> from the kernel like udev. If the system generates many hotplug events
> this mode of operation will consume less resources than registering
> mdev as hotplug helper or using the
