Received: by 10.213.65.68 with SMTP id h4csp3425589imn; Tue, 3 Apr 2018 04:53:44 -0700 (PDT) X-Google-Smtp-Source: AIpwx49IL2MZ7VyD36AjzjdAotCNFJBYAeRwMIKsyCbmRgRmxc6X4X0itlMZw99mpUg6GrA5C3HN X-Received: by 10.101.73.207 with SMTP id t15mr9079996pgs.204.1522756424325; Tue, 03 Apr 2018 04:53:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522756424; cv=none; d=google.com; s=arc-20160816; b=ZuhYVetgE5fpJl6aypDMCA4F5KFATqkgIwTAnb8MTqTTB8EMWFB+l5hIpBbWuo3GrK jZag6/V58chfNDe7VFvzMyB/jnzmqrCDx/m6PT/fE0mjPayHqEFjmiscwN1P+rGRMaHk DJro9WGwwPWVmeWWvm+jPMF1OQiY4QdPFRFW2JeKx/1P/87FHiiFfbZyZJwKEZLUjUmB eUVgjqE1GVvCoqs8GJIj8yagkK3VhA+rLDZYiyhYiRmoC98gDyvc5hvaAUhmDUNwVW8K sLVT2HEBGXu3+BvOa1yEiWuuuwJy3mNd0MW+00294S+NND6oXjyoejzOWsgoXoMBF5LC 3OVw== 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=a0LZn51nuvHlpZv/So6xIgYTv6iLSCj2pb5u17T0C6g=; b=KYOQy1cXCeyS/Jrduftj3jz8zvnnw2HsR8zlNYawUSNKhP/PmRVuJgywJyoNJk9gc5 cbYVBXYqssufCU/7YmCoYBo9Ag/AFWxwXqkeRKUMTKjWC8Amzmcp/3OyJgJoSdlatDIt Ef46UeCzLeBM6/yILvicWr8aesILS9O4uuUUckF5skuBQ/kKlJRs6nSDka5Q1EzSZKYW 88pmTMGwYv5sfFDg4PEm9uYYx7T3fGZ+Ve8T0b0oicjt1Cw1aIGaT7E/hhcEpidcTBei otn8L4dgzAEauaenpGee41tH87mehD54n3tN0bqNhWUhO3Xug5qYKgvnmAR89jqNISHd OpIw== 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 m1si266888pff.43.2018.04.03.04.53.30; Tue, 03 Apr 2018 04:53:44 -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 S932100AbeDCLwC (ORCPT + 99 others); Tue, 3 Apr 2018 07:52:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:49578 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755435AbeDCLwB (ORCPT ); Tue, 3 Apr 2018 07:52:01 -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 B1A822133F; Tue, 3 Apr 2018 11:51:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1A822133F 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: Tue, 3 Apr 2018 07:51:58 -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: <20180403075158.0c0a2795@gandalf.local.home> In-Reply-To: <20180403110612.GM5501@dhcp22.suse.cz> References: <1522320104-6573-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20180330102038.2378925b@gandalf.local.home> <20180403110612.GM5501@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 Tue, 3 Apr 2018 13:06:12 +0200 Michal Hocko wrote: > > I wonder if I should have the ring buffer allocate groups of pages, to > > avoid this. Or try to allocate with NORETRY, one page at a time, and > > when that fails, allocate groups of pages with RETRY_MAYFAIL, and that > > may keep it from causing an OOM? > > I wonder why it really matters. The interface is root only and we expect > some sanity from an admin, right? So allocating such a large ring buffer > that it sends the system to the OOM is a sign that the admin should be > more careful. Balancing on the OOM edge is always a risk and the result > will highly depend on the workload running in parallel. This came up because there's scripts or programs that set the size of the ring buffer. The complaint was that the application would just set the size to something bigger than what was available and cause an OOM killing other applications. The final solution is to simply check the available memory before allocating the ring buffer: /* Check if the available memory is there first */ i = si_mem_available(); if (i < nr_pages) return -ENOMEM; And it works well. -- Steve