From: Willy Tarreau <w@1wt.eu>
To: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
socketpair@gmail.com,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: Re: [PATCH v2] pipe: limit the per-user amount of pages allocated in pipes
Date: Mon, 11 Jan 2016 13:37:47 +0100 [thread overview]
Message-ID: <20160111123747.GA20127@1wt.eu> (raw)
In-Reply-To: <201601111226.u0BCQ1gv031473@mail.home.local>
On Mon, Jan 11, 2016 at 12:26:20PM +0000, Willy Tarreau wrote:
> This patch makes it possible to enforce a per-user limit above which
> new pipes will be limited to a single page, effectively limiting them
> to 4 kB each. This has the effect of protecting the system against
> memory abuse without hurting other users, and still allowing pipes to
> work correctly though with less data at once.
>
> The limit is controlled by the new sysctl user-max-pipe-pages, and may
> be disabled by setting it to zero. The default limit allows the default
> number of FDs per process (1024) to create pipes of the default size
> (64kB), thus reaching a limit of 64MB before starting to create only
> smaller pipes. With 256 processes limited to 1024 FDs each, this results
> in 1024*64kB + (256*1024 - 1024) * 4kB = 1084 MB of memory allocated for
> a user.
Regarding this, I was wondering if we shouldn't go a bit further and provide
two limits instead of one : a soft and a hard limit. The soft limit would be
the number of pages per user above which pipes are limited to a single page
(what is implemented in the current patch). The hard limit would make any
pipe creation attempt fail once reached. This way it would be possible to
enforce a strict limit without limiting the number of processes or FDs too
aggressively.
This could be done easily in alloc_pipe_info() :
+ if (too_many_pipe_buffers_hard(user))
+ return NULL;
+
if (too_many_pipe_buffers(user))
pipe_bufs = 1;
I'm just having a hard time imagining acceptable names for the syscalls :-/
Willy
next prev parent reply other threads:[~2016-01-11 12:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-11 8:56 [PATCH v2] pipe: limit the per-user amount of pages allocated in pipes Willy Tarreau
2016-01-11 12:37 ` Willy Tarreau [this message]
2016-01-11 12:38 ` Willy Tarreau
2016-01-11 16:19 ` Tetsuo Handa
2016-01-11 16:24 ` Willy Tarreau
2016-01-11 16:45 ` Tetsuo Handa
-- strict thread matches above, loose matches on Subject: below --
2016-01-11 12:26 Willy Tarreau
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=20160111123747.GA20127@1wt.eu \
--to=w@1wt.eu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=socketpair@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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.