From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by kanga.kvack.org (Postfix) with ESMTP id 027D482FAC for ; Tue, 6 Oct 2015 04:55:35 -0400 (EDT) Received: by igcpb10 with SMTP id pb10so82171095igc.1 for ; Tue, 06 Oct 2015 01:55:34 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com. [2607:f8b0:4001:c06::22e]) by mx.google.com with ESMTPS id e9si12236661igi.58.2015.10.06.01.55.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2015 01:55:34 -0700 (PDT) Received: by ioii196 with SMTP id i196so213783726ioi.3 for ; Tue, 06 Oct 2015 01:55:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20150922160608.GA2716@redhat.com> <20150923205923.GB19054@dhcp22.suse.cz> <20150925093556.GF16497@dhcp22.suse.cz> <201509260114.ADI35946.OtHOVFOMJQFLFS@I-love.SAKURA.ne.jp> <201509290118.BCJ43256.tSFFFMOLHVOJOQ@I-love.SAKURA.ne.jp> <20151002123639.GA13914@dhcp22.suse.cz> <87k2r0ph21.fsf@x220.int.ebiederm.org> Date: Tue, 6 Oct 2015 09:55:33 +0100 Message-ID: Subject: Re: can't oom-kill zap the victim's memory? From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: "Eric W. Biederman" Cc: Michal Hocko , Tetsuo Handa , David Rientjes , Oleg Nesterov , Kyle Walker , Christoph Lameter , Andrew Morton , Johannes Weiner , Vladimir Davydov , linux-mm , Linux Kernel Mailing List , Stanislav Kozina On Tue, Oct 6, 2015 at 9:49 AM, Linus Torvalds wrote: > > The basic fact remains: kernel allocations are so important that > rather than fail, you should kill user space. Only kernel allocations > that *explicitly* know that they have fallback code should fail, and > they should just do the __GFP_NORETRY. To be clear: "big" orders (I forget if the limit is at order-3 or order-4) do fail much more aggressively. But no, we do not limit retry to just order-0, because even small kmalloc sizes tend to often do order-1 or order-2 just because of memory packing issues (ie trying to pack into a single page wastes too much memory if the allocation sizes don't come out right). So no, order-0 isn't special. 1/2 are rather important too. [ Checking /proc/slabinfo: it looks like several slabs are order-3, for things like files_cache, signal_cache and sighand_cache for me at least. So I think it's up to order-3 that we basically need to consider "we'll need to shrink user space aggressively unless we have an explicit fallback for the allocation" ] Linus -- 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: email@kvack.org