All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Aleksa Sarai <cyphar@cyphar.com>, Max Kellermann <mk@cm4all.com>
Cc: Tejun Heo <tj@kernel.org>,
	cgroups@vger.kernel.org, lizefan@huawei.com,
	Johannes Weiner <hannes@cmpxchg.org>,
	max@duempel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cgroup_pids: add fork limit
Date: Tue, 10 Nov 2015 10:58:39 -0500	[thread overview]
Message-ID: <5642142F.2090302@gmail.com> (raw)
In-Reply-To: <CAOviyaiXSCztjv0d99G-t-yo1wtGzXZr0qpuqcKDBdV=wnMinw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

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.  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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-11-10 15:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10 14:06 [PATCH] cgroup_pids: add fork limit Max Kellermann
     [not found] ` <144716440621.20175.1000688899886388119.stgit-Rjmu19FXx3rR8JxBgnUBv+rzNCUFrscg@public.gmane.org>
2015-11-10 15:12   ` Tejun Heo
2015-11-10 15:12     ` Tejun Heo
2015-11-10 15:37     ` Max Kellermann
     [not found]       ` <20151110153746.GA20758-Rjmu19FXx3rR8JxBgnUBv+rzNCUFrscg@public.gmane.org>
2015-11-10 15:44         ` Tejun Heo
2015-11-10 15:44           ` Tejun Heo
2015-11-10 17:06         ` Max Kellermann
2015-11-10 17:06           ` Max Kellermann
2015-11-10 17:29           ` Tejun Heo
     [not found]             ` <20151110172915.GA13740-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2015-11-10 17:52               ` Max Kellermann
2015-11-10 17:52                 ` Max Kellermann
2015-11-10 15:25   ` Aleksa Sarai
2015-11-10 15:25     ` Aleksa Sarai
2015-11-10 15:58     ` Austin S Hemmelgarn [this message]
2015-11-10 16:19       ` Parav Pandit
2015-11-10 19:54         ` Austin S Hemmelgarn
     [not found]           ` <56424B83.2080504-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-11-15 13:36             ` Aleksa Sarai
2015-11-15 13:36               ` Aleksa Sarai
     [not found]               ` <CAOviyag=rHcDZj3MBR3dMbkdaOY=h1FB-78QLM3CZQe2WrrgCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-16 17:02                 ` Austin S Hemmelgarn
2015-11-16 17:02                   ` Austin S Hemmelgarn
2015-11-10 16:01     ` Max Kellermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5642142F.2090302@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=max@duempel.org \
    --cc=mk@cm4all.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.