Received: by 10.213.65.68 with SMTP id h4csp783851imn; Wed, 4 Apr 2018 07:13:23 -0700 (PDT) X-Google-Smtp-Source: AIpwx48kJ2ng5d/yX8X13cwGJfS3sexmKendl2v1vzXo02CvToWIJrQJh8jXtkHbuP7z3Dl/ZE7R X-Received: by 10.98.225.20 with SMTP id q20mr14026658pfh.142.1522851203222; Wed, 04 Apr 2018 07:13:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522851203; cv=none; d=google.com; s=arc-20160816; b=cQl7Hh3dCwiDc+j3Io63+Pqb4g7W+UVgpYYwQjxP203CQ0A1VOO9+o77fZCtPKtJ06 RQrE6NjllS4JB70c2ErMldTnm/WxZHMgMoF8RCzzxmojqvOb0Nv8Y6RzaWaTVHxpItK/ w60ygMqskmQx7inM62nFxHLL26HLR3l6EtcqktsFmGXdNfopXqXQSeRCT3kmuzUCyP7H HmSAmL5/fmdZuZDWcBJzb2bEyOHn2tS+hMKudSbL7rvm9bxoqLX1/B9XSlaF0lxAyrdp z2i+b2lnM6RvvPOvcV+gnCu55L2RpJa7G3D2GjNrucwS26q+LqiKe85f/1FOyAkSbUgd Q8jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=MgaNVGMr7JFhHSBmEooGYw8ibm72j+oyDiZcVHJDl+o=; b=boQKottHP8PKkbuZA8yx6VNMKoc79GRRoecJjaYTZA9pOCCQv9SyFwOqYcEMvJM66x lCo9EGm1NyspJiBCQ770tonKsXLfKF2phf6956bZPDjJnaLVDXk2clibIBiQgTmvZ3Iv c4MGzn1KRgban0CRmZhe4k0n0ME+F09Q2Ej1Q4/15bpjbcm+dl1Onp0SNerLE3HtJnqZ vuwZ5JTDlxZGBgcmocMMUcCqXIzjzKjbd+AsEbzZAt0+K6T2lPY0hZRXMc7xEOcnIcr7 X5QEm0nkRXGfwuVTJwjXkGg4m1S3gvGCYQkpDzJW82IOmFmLxAqLdDkLmFoiFStZ75y8 k2iQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w2-v6si3264415plk.702.2018.04.04.07.13.09; Wed, 04 Apr 2018 07:13:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751410AbeDDOLz (ORCPT + 99 others); Wed, 4 Apr 2018 10:11:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:41718 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751213AbeDDOLy (ORCPT ); Wed, 4 Apr 2018 10:11:54 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D21D22133F; Wed, 4 Apr 2018 14:11:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D21D22133F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 4 Apr 2018 10:11:49 -0400 From: Steven Rostedt To: Michal Hocko Cc: Zhaoyang Huang , Ingo Molnar , linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org, Andrew Morton , Joel Fernandes , linux-mm@kvack.org, Vlastimil Babka Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem Message-ID: <20180404101149.08f6f881@gandalf.local.home> In-Reply-To: <20180404062340.GD6312@dhcp22.suse.cz> References: <1522320104-6573-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20180330102038.2378925b@gandalf.local.home> <20180403110612.GM5501@dhcp22.suse.cz> <20180403075158.0c0a2795@gandalf.local.home> <20180403121614.GV5501@dhcp22.suse.cz> <20180403082348.28cd3c1c@gandalf.local.home> <20180403123514.GX5501@dhcp22.suse.cz> <20180403093245.43e7e77c@gandalf.local.home> <20180403135607.GC5501@dhcp22.suse.cz> <20180404062340.GD6312@dhcp22.suse.cz> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Apr 2018 08:23:40 +0200 Michal Hocko wrote: > If you are afraid of that then you can have a look at {set,clear}_current_oom_origin() > which will automatically select the current process as an oom victim and > kill it. Would it even receive the signal? Does alloc_pages_node() even respond to signals? Because the OOM happens while the allocation loop is running. I tried it out, I did the following: set_current_oom_origin(); for (i = 0; i < nr_pages; i++) { struct page *page; /* * __GFP_RETRY_MAYFAIL flag makes sure that the allocation fails * gracefully without invoking oom-killer and the system is not * destabilized. */ bpage = kzalloc_node(ALIGN(sizeof(*bpage), cache_line_size()), GFP_KERNEL | __GFP_RETRY_MAYFAIL, cpu_to_node(cpu)); if (!bpage) goto free_pages; list_add(&bpage->list, pages); page = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL | __GFP_RETRY_MAYFAIL, 0); if (!page) goto free_pages; bpage->page = page_address(page); rb_init_page(bpage->page); } clear_current_oom_origin(); The first time I ran my ring buffer memory stress test, it killed the stress test. The second time I ran it, it killed polkitd. Still doesn't help as much as the original patch. You haven't convinced me that using si_mem_available() is a bad idea. If anything, you've solidified my confidence in it. -- Steve