From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753109AbbJFPAx (ORCPT ); Tue, 6 Oct 2015 11:00:53 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:53782 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753063AbbJFPAt (ORCPT ); Tue, 6 Oct 2015 11:00:49 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds 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 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, 06 Oct 2015 09:52:50 -0500 In-Reply-To: (Linus Torvalds's message of "Tue, 6 Oct 2015 09:55:33 +0100") Message-ID: <87lhbgf3r1.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18MEmuw8fomxjSBePH4C/3Hhedw/YyY8Ck= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Linus Torvalds X-Spam-Relay-Country: X-Spam-Timing: total 572 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.1 (0.5%), b_tie_ro: 2.1 (0.4%), parse: 1.04 (0.2%), extract_message_metadata: 18 (3.1%), get_uri_detail_list: 2.4 (0.4%), tests_pri_-1000: 8 (1.4%), tests_pri_-950: 1.35 (0.2%), tests_pri_-900: 1.17 (0.2%), tests_pri_-400: 39 (6.9%), check_bayes: 38 (6.6%), b_tokenize: 11 (1.9%), b_tok_get_all: 10 (1.8%), b_comp_prob: 3.5 (0.6%), b_tok_touch_all: 9 (1.6%), b_finish: 0.76 (0.1%), tests_pri_0: 491 (85.8%), tests_pri_500: 4.5 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: can't oom-kill zap the victim's memory? X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds writes: > 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. If you have reached the point of killing userspace you might as well panic the box. Userspace will recover more cleanly and more quickly. The oom-killer is like an oops. Nice for debugging but not something you want on a production workload. > 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). I am not asking that we limit retry to just order-0 pages. I am asking that we limit the oom-killer on failure to just order-0 pages. > So no, order-0 isn't special. 1/2 are rather important too. That is a justification for retrying. That is not a justification for killing the box. > [ 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" ] What I know is that order-3 is definitely too big. I had 4G of RAM free. I needed 16K to exapand the fd table. The box died. That is not good. We have static checkers now, failure to check and handle errors tends to be caught. So yes for the rare case of order-[123] allocations failing we should return the failure to the caller. The kernel can handle it. Userspace can handle just about anything better than random processes dying. Eric