From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: axboe@kernel.dk, oleg@redhat.com, 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: Tue, 5 Dec 2017 18:34:59 +0300 [thread overview]
Message-ID: <7f440fd7-872e-ff17-a152-6ef6dbd10a4e@virtuozzo.com> (raw)
In-Reply-To: <20171205151532.5evofjjma2zg3kte@dhcp22.suse.cz>
On 05.12.2017 18:15, Michal Hocko wrote:
> On Tue 05-12-17 13:00:54, Kirill Tkhai wrote:
>> Currently, number of available aio requests may be
>> limited only globally. There are two sysctl variables
>> aio_max_nr and aio_nr, which implement the limitation
>> and request accounting. They help to avoid
>> the situation, when all the memory is eaten in-flight
>> requests, which are written by slow block device,
>> and which can't be reclaimed by shrinker.
>>
>> 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
>>
>> The patch allows to fix the problem. It adds memcg
>> accounting of user used aio data (the biggest is
>> the bunch of aio_kiocb; ring buffer is the second
>> biggest), so a user of a certain memcg won't be able
>> to allocate more aio requests memory, then the cgroup
>> allows, and he will bumped into the limit.
>
> So what happens when we hit the hard limit and oom kill somebody?
> Are those charged objects somehow bound to a process context?
There is exit_aio() called from __mmput(), which waits till
the charged objects complete and decrement reference counter.
If there was a problem with oom in memcg, there would be
the same problem on global oom, as it can be seen there is
no __GFP_NOFAIL flags anywhere in aio code.
But it seems everything is safe.
Kirill
next prev parent reply other threads:[~2017-12-05 15:34 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 [this message]
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
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=7f440fd7-872e-ff17-a152-6ef6dbd10a4e@virtuozzo.com \
--to=ktkhai@virtuozzo.com \
--cc=axboe@kernel.dk \
--cc=bcrl@kvack.org \
--cc=jmoyer@redhat.com \
--cc=linux-aio@kvack.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=oleg@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox