From: Nikolay Borisov <kernel@kyup.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Theodore Ts'o <tytso@mit.edu>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dmitry Monakhov <dmonakhov@virtuozzo.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH RFC] ext4: use __GFP_NOFAIL in ext4_free_blocks()
Date: Thu, 25 Feb 2016 11:12:08 +0200 [thread overview]
Message-ID: <56CEC568.6080809@kyup.com> (raw)
In-Reply-To: <20160225090839.GC17573@dhcp22.suse.cz>
On 02/25/2016 11:08 AM, Michal Hocko wrote:
> On Thu 25-02-16 11:01:32, Nikolay Borisov wrote:
>>
>>
>> On 02/24/2016 07:09 PM, Konstantin Khlebnikov wrote:
>>> This might be unexpected but pages allocated for sbi->s_buddy_cache are
>>> charged to current memory cgroup. So, GFP_NOFS allocation could fail if
>>> current task has been killed by OOM or if current memory cgroup has no
>>> free memory left. Block allocator cannot handle such failures here yet.
>>>
>>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>
>> Adding new users of GFP_NOFAIL is deprecated.
>
> This is not true. GFP_NOFAIL should be used where the allocation failure
> is no tolleratable and it is much more preferrable to doing an opencoded
> endless loop over page allocator.
In that case the comments in buffered_rmqueue, and the WARN_ON in
__alloc_pages_may_oom and __alloc_pages_slowpath perhaps should be
removed since they are misleading?
>
>> Where exactly does the
>> block allocator fail, I skimmed the code and failing ext4_mb_load_buddy
>> seems to be handled at all call sites. There are some BUG_ONs but from
>> the comments there I guess they should occur when we try to find a page
>> and not allocate a new one?
>
> I have posted a similar patch last year:
> http://lkml.kernel.org/r/1438768284-30927-6-git-send-email-mhocko@kernel.org
> because I could see emergency reboots when GFP_NOFS allocations were
> allowed to fail.
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Nikolay Borisov <kernel@kyup.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
"Theodore Ts'o" <tytso@mit.edu>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dmitry Monakhov <dmonakhov@virtuozzo.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH RFC] ext4: use __GFP_NOFAIL in ext4_free_blocks()
Date: Thu, 25 Feb 2016 11:12:08 +0200 [thread overview]
Message-ID: <56CEC568.6080809@kyup.com> (raw)
In-Reply-To: <20160225090839.GC17573@dhcp22.suse.cz>
On 02/25/2016 11:08 AM, Michal Hocko wrote:
> On Thu 25-02-16 11:01:32, Nikolay Borisov wrote:
>>
>>
>> On 02/24/2016 07:09 PM, Konstantin Khlebnikov wrote:
>>> This might be unexpected but pages allocated for sbi->s_buddy_cache are
>>> charged to current memory cgroup. So, GFP_NOFS allocation could fail if
>>> current task has been killed by OOM or if current memory cgroup has no
>>> free memory left. Block allocator cannot handle such failures here yet.
>>>
>>> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
>>
>> Adding new users of GFP_NOFAIL is deprecated.
>
> This is not true. GFP_NOFAIL should be used where the allocation failure
> is no tolleratable and it is much more preferrable to doing an opencoded
> endless loop over page allocator.
In that case the comments in buffered_rmqueue, and the WARN_ON in
__alloc_pages_may_oom and __alloc_pages_slowpath perhaps should be
removed since they are misleading?
>
>> Where exactly does the
>> block allocator fail, I skimmed the code and failing ext4_mb_load_buddy
>> seems to be handled at all call sites. There are some BUG_ONs but from
>> the comments there I guess they should occur when we try to find a page
>> and not allocate a new one?
>
> I have posted a similar patch last year:
> http://lkml.kernel.org/r/1438768284-30927-6-git-send-email-mhocko@kernel.org
> because I could see emergency reboots when GFP_NOFS allocations were
> allowed to fail.
>
next prev parent reply other threads:[~2016-02-25 9:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 17:09 [PATCH RFC] ext4: use __GFP_NOFAIL in ext4_free_blocks() Konstantin Khlebnikov
2016-02-24 17:09 ` Konstantin Khlebnikov
2016-02-25 9:01 ` Nikolay Borisov
2016-02-25 9:01 ` Nikolay Borisov
2016-02-25 9:08 ` Michal Hocko
2016-02-25 9:08 ` Michal Hocko
2016-02-25 9:12 ` Nikolay Borisov [this message]
2016-02-25 9:12 ` Nikolay Borisov
2016-02-25 10:27 ` Michal Hocko
2016-02-25 10:27 ` Michal Hocko
2016-03-13 21:30 ` Theodore Ts'o
2016-03-13 21:30 ` Theodore Ts'o
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=56CEC568.6080809@kyup.com \
--to=kernel@kyup.com \
--cc=dmonakhov@virtuozzo.com \
--cc=hannes@cmpxchg.org \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=tytso@mit.edu \
/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.