[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac949d08-72ff-edf6-6526-fdc9ad602631@csgroup.eu>
Date: Sat, 24 Apr 2021 14:21:11 +0200
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Peter Enderborg <peter.enderborg@...y.com>,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
Guenter Roeck <linux@...ck-us.net>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-watchdog@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [RFC PATCH] watchdog: Adding softwatchdog
Le 24/04/2021 à 12:25, Peter Enderborg a écrit :
> This is not a rebooting watchdog. It's function is to take other
> actions than a hard reboot. On many complex system there is some
> kind of manager that monitor and take action on slow systems.
> Android has it's lowmemorykiller (lmkd), desktops has earlyoom.
> This watchdog can be used to help monitor to preform some basic
> action to keep the monitor running.
>
> It can also be used standalone. This add a policy that is
> killing the process with highest oom_score_adj and using
> oom functions to it quickly. I think it is a good usecase
> for the patch. Memory siuations can be problematic for
> software that monitor system, but other prolicys can
> should also be possible. Like picking tasks from a memcg, or
> specific UID's or what ever is low priority.
I'm nore sure I understand the reasoning behind the choice of oom logic to decide which task to kill.
Usually a watchdog will detect if a task is using 100% of the CPU time. If such a task exists, it is
the one running, not another one that has huge amount of memory allocated by spends like 1% of CPU time.
So if there is a task to kill by a watchdog, I would say it is the current task.
Another remark: you are using regular timers as far as I understand. I remember having problems with
that in the past, it required the use of hrtimers. I can't remember the details exactly but you can
look at commit https://github.com/linuxppc/linux/commit/1ff688209
Christophe
Powered by blists - more mailing lists