From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07AECC433B4 for ; Sat, 24 Apr 2021 15:24:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D861661158 for ; Sat, 24 Apr 2021 15:24:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233846AbhDXPYw (ORCPT ); Sat, 24 Apr 2021 11:24:52 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:52397 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233833AbhDXPYv (ORCPT ); Sat, 24 Apr 2021 11:24:51 -0400 Received: from fsav303.sakura.ne.jp (fsav303.sakura.ne.jp [153.120.85.134]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 13OFNbNP083442; Sun, 25 Apr 2021 00:23:37 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav303.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav303.sakura.ne.jp); Sun, 25 Apr 2021 00:23:37 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav303.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 13OFNbuq083438 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Apr 2021 00:23:37 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [RFC PATCH] watchdog: Adding softwatchdog To: Guenter Roeck , Peter Enderborg , Wim Van Sebroeck , Andrew Morton , linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt References: <20210424102555.28203-1-peter.enderborg@sony.com> <20210424102555.28203-2-peter.enderborg@sony.com> From: Tetsuo Handa Message-ID: <844e3ecb-62c3-856a-7273-e22eee35e80f@i-love.sakura.ne.jp> Date: Sun, 25 Apr 2021 00:23:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-watchdog@vger.kernel.org On 2021/04/24 23:41, Guenter Roeck wrote: > On 4/24/21 3:25 AM, Peter Enderborg wrote: >> 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. >> --- > > NACK. Besides this not following the new watchdog API, the task > of a watchdog is to reset the system on failure. Its task is most > definitely not to re-implement the oom killer in any way, shape, > or form. > I don't think this proposal is a watchdog. I think this proposal is a timer based process killer, based on an assumption that any slowdown which prevents the monitor process from pinging for more than 0.5 seconds (if HZ == 1000) is caused by memory pressure.