From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752363Ab1LLJjO (ORCPT ); Mon, 12 Dec 2011 04:39:14 -0500 Received: from [205.233.59.134] ([205.233.59.134]:33237 "EHLO merlin.infradead.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752221Ab1LLJjN convert rfc822-to-8bit (ORCPT ); Mon, 12 Dec 2011 04:39:13 -0500 Message-ID: <1323682702.16764.59.camel@twins> Subject: Re: [PATCH] Softlockup (out of cpu) killer From: Peter Zijlstra To: Vincent Li Cc: Ingo Molnar , Don Zickus , Andrew Morton , Mandeep Singh Baines , linux-kernel@vger.kernel.org Date: Mon, 12 Dec 2011 10:38:22 +0100 In-Reply-To: <1323643735-1999-1-git-send-email-vincent.mc.li@gmail.com> References: <1323643735-1999-1-git-send-email-vincent.mc.li@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.2.1- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2011-12-11 at 14:48 -0800, Vincent Li wrote: > In kernel, there is out of memory (OOM) killer, why not make an out of cpu (OOC) killer? > I tested following patch by running an user-space cpu hogging process and the softlockukp > detector killed the process successfully. > > Softlockup could be caused by user-space process hogging cpu, add softlockup_kill kernel > config to allow kernel to kill the user space cpu hogging process. this feature is > useful for high availability systems that have uptime gurantees and where a softlockup > must be resolved ASAP > > echo 1 > /proc/sys/kernel/softlockukp_kill to enable cpu hog process killer > echo 0 > /proc/sys/kernel/softlockup_kill to disable cpu hog process killer > > Signed-off-by: Vincent Li Your whole premise is broken. Being a cpu hog and the softlockup mechanism aren't related at all. Furthermore, since the normal scheduling policy is a proportional one, a cpu hog can't in fact starve anybody (although a fork bomb could). And FIFO/RR are privileged ops. Furthermore the distinction between memory and cpu-time is that memory isn't a renewable resource, whereas time is. There's always more time, but there's not always more memory. So no, I don't think either you patch nor your concept make any sense. Consider it nacked.