On Thu 25-02-16 11:12:08, Nikolay Borisov wrote: > > > 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@xxxxxxxxxxxxxx> > >> > >> 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, yes, will post the patch. The warning for order > 1 is still valid. > and the WARN_ON in > __alloc_pages_may_oom and __alloc_pages_slowpath perhaps should be > removed since they are misleading? We are only warning about absurd cases where __GFP_NOFAIL doesn't make any sense. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>