Received: by 10.213.65.68 with SMTP id h4csp882061imn; Wed, 4 Apr 2018 08:49:24 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/mvIlnXH7IbjU61XeLmmdiUaWD3/EMazQnooKbPncojYc8SvkZ64/sRXhifjCIWOD/DOTs X-Received: by 10.99.96.19 with SMTP id u19mr12001362pgb.261.1522856964336; Wed, 04 Apr 2018 08:49:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522856964; cv=none; d=google.com; s=arc-20160816; b=srJETRIbAO+uGGlaJWlhNzaMnEEULcWysz5Zryolo2RZjm/vgqzn+e6OVFQNwEkGDs Kh2kGMl+0wLrqxpaoQnyl3vwzxniRG8wOSNvtWQsV3QzRuhwGdJqdCJKze9CrRpvObuT /LbaTSy2hGOMJ5ti0k1zq0ZPv+lREIQD7ydkp8qL+qdPBxhPpbeJD9Y4mQ+6J71WWr0C lNdiko5sE1fXNkJNkFgBjGLLkZ8HU6EMIf9xk/VyHut8X+AF3NdSeHrX+rUENodtxavn AiHi0sOCrwiCrSJ3dEQDQIhs78KMUHaJnbpVnMr9yJeUn+Y4/ZXDDZXGKaEttCBpdqju vczQ== 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=4xHgdOgdsg6ULRsxPiELaH6rHNpcM6wOY3vhOU4JuFU=; b=P470lsUsfUgSXdevQqGewRzm+qJwgNeigxzQqFgiDS59HVLML/ZldGwYRqxXxWfd4N wrOIm7mYcoctNbWJ9PMesD7LYzhx0+Q0h67MscuuFkoeeLW4Zta3PsMmB9u/h72pw3yV WxuBTI6WXPLLNvJ6VTdFXVy5TiAUBNxMuiDmjim2Vfu6L5O+gtQq426ZJ71GT3+T23DF Gwusgup0yJque0lTexbc+UbKBQj25syEWuviYqtzuRlaKjiBYbYV0MZwOW4AZgKpo6H/ y8CRZ+81R2y0Gm8AGUA5Zug95SwkTGV9caiw66EQHn/9sF82tWxcBcNsXJucwOlz4nAj 32sA== 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 c11-v6si5629996pls.97.2018.04.04.08.49.10; Wed, 04 Apr 2018 08:49:24 -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 S1752286AbeDDPre (ORCPT + 99 others); Wed, 4 Apr 2018 11:47:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:50126 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751696AbeDDPrd (ORCPT ); Wed, 4 Apr 2018 11:47:33 -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 7D13A20838; Wed, 4 Apr 2018 15:47:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D13A20838 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 11:47:30 -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: <20180404114730.65118279@gandalf.local.home> In-Reply-To: <20180404142329.GI6312@dhcp22.suse.cz> References: <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> <20180404101149.08f6f881@gandalf.local.home> <20180404142329.GI6312@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 16:23:29 +0200 Michal Hocko wrote: > > > > 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; > > if (fatal_signal_pending()) > fgoto free_pages; I originally was going to remove the RETRY_MAYFAIL, but adding this check (at the end of the loop though) appears to have OOM consistently kill this task. I still like to keep RETRY_MAYFAIL, because it wont trigger OOM if nothing comes in and tries to do an allocation, but instead will fail nicely with -ENOMEM. -- Steve > > > bpage->page = page_address(page); > > rb_init_page(bpage->page); > > } > > clear_current_oom_origin();