All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: Benjamin LaHaise <ben@communityfibre.ca>,
	Oleg Nesterov <oleg@redhat.com>
Cc: Tejun Heo <tj@kernel.org>,
	axboe@kernel.dk, viro@zeniv.linux.org.uk,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-aio@kvack.org
Subject: Re: [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup
Date: Wed, 6 Dec 2017 21:19:09 +0300	[thread overview]
Message-ID: <103a542b-58c0-5d31-7b51-2a957a5bbd66@virtuozzo.com> (raw)
In-Reply-To: <20171206174445.GM1493@kvack.org>

On 06.12.2017 20:44, Benjamin LaHaise wrote:
> On Wed, Dec 06, 2017 at 06:32:56PM +0100, Oleg Nesterov wrote:
>>>> This memory lives in page-cache/lru, it is visible for shrinker which
>>>> will unmap these pages for no reason on memory shortage. IOW, aio fools
>>>> the kernel, this memory looks reclaimable but it is not. And we only do
>>>> this for migration.
>>>
>>> It's the same as any other memory that's mlock()ed into RAM.
>>
>> No. Again, this memory is not properly accounted, and unlike mlock()ed
>> memory it is visible to shrinker which will do the unnecessary work on
>> memory shortage which in turn will lead to unnecessary page faults.
>>
>> So let me repeat, shouldn't we at least do mapping_set_unevictable() in
>> aio_private_file() ?
> 
> Send a patch then!  I don't know why you're asking rather than sending a
> patch to do this if you think it is needed.
> 
>>>> triggers OOM-killer which kills sshd and other daemons on my machine.
>>>> These pages were not even faulted in (or the shrinker can unmap them),
>>>> the kernel can not know who should be blamed.
>>>
>>> The OOM-killer killed the wrong process: News at 11.
>>
>> Well. I do not think we should blame OOM-killer in this case. But as I
>> said this is not a bug-report or something like this, I agree this is
>> a minor issue.
> 
> I do think the OOM-killer is doing the wrong thing here.  If process X is
> the only one that is allocating gobs of memory, why kill process Y that
> hasn't allocated memory in minutes or hours just because it is bigger?

I assume, if a process hasn't allocated memory in minutes or hours,
then the most probably all of its evictable memory has already been
moved to swap as its pages were last in lru list.

> We're not perfect at tracking who owns memory allocations, so why not
> factor in memory allocation rate when decided which process to kill?  We
> keep throwing bandaids on the OOM-killer by annotating allocations, and we
> keep missing the annotation of allocations.  Doesn't sound like a real fix
> for the underlying problem to me when a better heuristic would solve the
> current problem and probably several other future instances of the same
> problem.

Kirill

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

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 16:12 [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup Kirill Tkhai
2017-12-04 16:12 ` Kirill Tkhai
2017-12-04 16:12 ` [PATCH 1/5] aio: Move aio_nr increment to separate function Kirill Tkhai
2017-12-04 16:13 ` [PATCH 2/5] aio: Export aio_nr_lock and aio_max_nr initial value to include/linux/aio.h Kirill Tkhai
2017-12-04 16:13 ` [PATCH 3/5] blkcg: Add blkcg::blkg_aio_nr and blkcg::blkg_aio_max_nr Kirill Tkhai
2017-12-04 16:13 ` [PATCH 4/5] blkcg: Charge aio requests in blkio cgroup hierarchy Kirill Tkhai
2017-12-04 16:13 ` [PATCH 5/5] blkcg: Add cgroup file to configure blkcg::blkg_aio_max_nr Kirill Tkhai
2017-12-04 16:52 ` [PATCH 0/5] blkcg: Limit maximum number of aio requests available for cgroup Benjamin LaHaise
2017-12-04 21:27   ` Kirill Tkhai
2017-12-04 21:35     ` Jeff Moyer
2017-12-04 21:35       ` Jeff Moyer
2017-12-04 21:48       ` Kirill Tkhai
2017-12-04 20:07 ` Tejun Heo
2017-12-04 21:44   ` Kirill Tkhai
2017-12-04 21:52     ` Tejun Heo
2017-12-04 22:49       ` Kirill Tkhai
2017-12-04 22:59         ` Jeff Moyer
2017-12-04 22:59           ` Jeff Moyer
2017-12-04 23:14           ` Kirill Tkhai
2017-12-05 15:41             ` Jeff Moyer
2017-12-05 15:41               ` Jeff Moyer
2017-12-05 15:51               ` Tejun Heo
2017-12-04 23:02         ` Tejun Heo
2017-12-04 23:05           ` Kirill Tkhai
2017-12-05 15:19     ` Oleg Nesterov
2017-12-05 15:35       ` Benjamin LaHaise
2017-12-06 17:32         ` Oleg Nesterov
2017-12-06 17:44           ` Benjamin LaHaise
2017-12-06 17:44             ` Benjamin LaHaise
2017-12-06 18:19             ` Kirill Tkhai [this message]
2017-12-06 18:30               ` Benjamin LaHaise
2017-12-06 19:37                 ` Kirill Tkhai
2017-12-07 13:44             ` Oleg Nesterov

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=103a542b-58c0-5d31-7b51-2a957a5bbd66@virtuozzo.com \
    --to=ktkhai@virtuozzo.com \
    --cc=axboe@kernel.dk \
    --cc=ben@communityfibre.ca \
    --cc=linux-aio@kvack.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.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.