All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: axboe@kernel.dk, bcrl@kvack.org, tj@kernel.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-aio@kvack.org, jmoyer@redhat.com
Subject: Re: [PATCH] aio: Add memcg accounting of user used data
Date: Wed, 6 Dec 2017 13:43:21 +0100	[thread overview]
Message-ID: <20171206124321.GC7515@dhcp22.suse.cz> (raw)
In-Reply-To: <da69b3a4-f4a7-f957-5828-2edee2009b02@virtuozzo.com>

On Wed 06-12-17 15:36:56, Kirill Tkhai wrote:
> On 06.12.2017 15:23, Michal Hocko wrote:
> > On Tue 05-12-17 13:00:54, Kirill Tkhai wrote:
> > [...]
> >> This meets the problem in case of many containers
> >> are used on the hardware node. Since aio_max_nr is
> >> a global limit, any container may occupy the whole
> >> available aio requests, and to deprive others the
> >> possibility to use aio at all. The situation may
> >> happen because of evil intentions of the container's
> >> user or because of the program error, when the user
> >> makes this occasionally
> > 
> > I am sorry to beat more on this but finally got around to
> > http://lkml.kernel.org/r/17b22d53-ad3d-1ba8-854f-fc2a43d86c44@virtuozzo.com
> > and read the above paragraph once again. I can see how accounting to
> > a memcg helps to reduce the memory footprint but I fail to see how it
> > helps the above scenario. Could you clarify wow you set up a limit to
> > prevent anybody from DoSing other containers by depleting aio_max_nr?
> The memcg limit allows to increase aio_max_nr and the accounting guarantees
> container can't exceed the limit. You may configure the limit and aio_max_nr
> in the way, all containers requests in sum never reach aio_max_nr.

So you are essentially saying that you make aio_max_nr unlimited and
rely on the memory consumption tracking by memcg, right? Are there any
downsides (e.g. clog the AIO subsytem)?

Please make sure that all this in the changelog.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2017-12-06 12:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 10:00 [PATCH] aio: Add memcg accounting of user used data Kirill Tkhai
2017-12-05 15:15 ` Michal Hocko
2017-12-05 15:34   ` Kirill Tkhai
2017-12-05 15:43     ` Michal Hocko
2017-12-05 16:02       ` Kirill Tkhai
2017-12-06  9:05         ` Michal Hocko
2017-12-06 10:00           ` Kirill Tkhai
2017-12-06 12:23 ` Michal Hocko
2017-12-06 12:36   ` Kirill Tkhai
2017-12-06 12:43     ` Michal Hocko [this message]
2017-12-06 13:13       ` Kirill Tkhai

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=20171206124321.GC7515@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bcrl@kvack.org \
    --cc=jmoyer@redhat.com \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.