Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH] watchdog: Adding softwatchdog
To:     Peter Enderborg <peter.enderborg@sony.com>,
        Wim Van Sebroeck <wim@linux-watchdog.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Andrew Morton <akpm@linux-foundation.org>,
        linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, Shakeel Butt <shakeelb@google.com>
References: <20210424102555.28203-1-peter.enderborg@sony.com>
 <20210424102555.28203-2-peter.enderborg@sony.com>
From:   Christophe Leroy <christophe.leroy@csgroup.eu>
Message-ID: <ac949d08-72ff-edf6-6526-fdc9ad602631@csgroup.eu>
Date:   Sat, 24 Apr 2021 14:21:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <20210424102555.28203-2-peter.enderborg@sony.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Precedence: bulk


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