Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933152Ab1CZAEe (ORCPT ); Fri, 25 Mar 2011 20:04:34 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:35396 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932711Ab1CZAEP (ORCPT ); Fri, 25 Mar 2011 20:04:15 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i22EN2M3Vpp+pdz8eaFn9ulenM4GVA42TB/BG2rjVRgy+Yx4rjidsZIl+Fv3Di8aCY A6BGUVzyReF1+lWbtv+BWoGoR1fPHYUq468oF889f/AuXMwrpjbiDKxRkFZxcn0Ih/+Z Djpk3rQ8roDdN7hjrfEhHHAPh0eo2E76Kknsg= MIME-Version: 1.0 In-Reply-To: References: <20110324182240.5fe56de2.kamezawa.hiroyu@jp.fujitsu.com> <20110324105222.GA2625@barrios-desktop> <20110325090411.56c5e5b2.kamezawa.hiroyu@jp.fujitsu.com> <20110325115453.82a9736d.kamezawa.hiroyu@jp.fujitsu.com> Date: Sat, 26 Mar 2011 09:04:14 +0900 Message-ID: Subject: Re: [PATCH 0/4] forkbomb killer From: Hiroyuki Kamezawa To: Colin Walters Cc: Minchan Kim , KAMEZAWA Hiroyuki , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "rientjes@google.com" , Andrey Vagin , KOSAKI Motohiro , Hugh Dickins , Johannes Weiner , Rik van Riel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 28 If you set up cpu+memory cgroup properly, I think it works well. For well scheduled servers or some production devices, all applications and relationship of them can be designed properly and you can find the best cgroup set. For a some desktop environ like mine, which has 1-4G of memory, I think a user doesn't want to divide resources (limiting memory) for emergency because I want to use full resources of my poor host. Of course, I use memcg when I handle very big file or memory by an application when I can think of bad effects of that. And, with experiences in ML.... I've advised "please use memcg" when I see emails/questions about OOM....but there are still periodic OOM report to ML ;) Maybe usual users doesn't pay costs to avoid some emergency by themselves. (Some good daemon software should do that.) I feel the kernel itself should have the last resort to quit hard-to-recover status. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/