Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754160AbbKJQTQ (ORCPT ); Tue, 10 Nov 2015 11:19:16 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:35793 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754090AbbKJQTM (ORCPT ); Tue, 10 Nov 2015 11:19:12 -0500 MIME-Version: 1.0 In-Reply-To: <5642142F.2090302@gmail.com> References: <144716440621.20175.1000688899886388119.stgit@rabbit.intern.cm-ag> <5642142F.2090302@gmail.com> Date: Tue, 10 Nov 2015 21:49:11 +0530 Message-ID: Subject: Re: [PATCH] cgroup_pids: add fork limit From: Parav Pandit To: Austin S Hemmelgarn Cc: Aleksa Sarai , Max Kellermann , Tejun Heo , cgroups@vger.kernel.org, lizefan@huawei.com, Johannes Weiner , max@duempel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2016 Lines: 39 On Tue, Nov 10, 2015 at 9:28 PM, Austin S Hemmelgarn wrote: > On 2015-11-10 10:25, Aleksa Sarai wrote: >> >> Processes don't "use up resources" after they've died and been freed >> (which is dealt with inside PIDs). Yes, lots of small processes that >> die quickly could (in principle) make hard work for the scheduler, but >> I don't see how "time spent scheduling in general" is a resource... >> Fork bombs aren't bad because they cause a lot of fork()s, they're bad >> because the *create a bunch of processes that use up memory*, which >> happens because they call fork() a bunch of times and **don't >> exit()**. > > While I'm indifferent about the patch, I would like to point out that > fork-bombs are also bad because they eat _a lot_ of processor time, and I've > seen ones designed to bring a system to it's knees just by saturating the > processor with calls to fork() (which is as slow as or slower than stat() on > many commodity systems, setting up the various structures for a new process > is an expensive operation) and clogging up the scheduler. Isn't cpu cgroup helpful there to limit it? Are you saying time spent by scheduler is more that actually affects the scheduling of processes of other threads? If so, could you share little more insight on how that time measure outside of the cpu's cgroup cycles? Just so that its helpful to wider audience. > This isn't as > evident of course when you run a fork-bomb on a laptop or similar system, > because you run out of memory and PID's before the latency from scheduling > and so many processes calling fork really starts to become noticeable, but > when you start to look at really big systems (on the order of hundreds of GB > of RAM), it does become much more noticeable. > -- 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/