Received: by 10.213.65.68 with SMTP id h4csp147980imn; Fri, 30 Mar 2018 16:40:22 -0700 (PDT) X-Google-Smtp-Source: AIpwx48MJ2GnnRIwwmQmQLkwy8BYFrxKU8hKHmH81T3jMvnqp1j3T/3EY0lM36zjEjFqlxX2Zpsz X-Received: by 2002:a17:902:9a44:: with SMTP id x4-v6mr734799plv.312.1522453222118; Fri, 30 Mar 2018 16:40:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522453222; cv=none; d=google.com; s=arc-20160816; b=YK5JVSjtZ6lchYby3aQYkFpOlAnkWqGdgZgKMrXpbSRnXEpMUsrgJ99ukfl6ULJ5Ib WO1il5CfoAtvIGS3tsist6FotqIKZfqGKAa2pS/4dWw/HeIx0lbDVb9stmLZ+c8Uz7eq tOZP1Fh2OWBcd5WJvyQCDtkSEu321Rng2YfjL7IrbXt/X2+uKSOG4rfra1Xomjo6EQz5 AsDQNel/Uuadnhi21BM5j0sChW+rLAZpRjiGvbjAEFVjEp38emjpW/mKizeUajZ0uZoo pOyhGF2hpXG7u9QKwe3aFz/yYjOHkbSgIj77hfVz+oyExwqHvgIUi+GFlZ39JfrY3A89 7+cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=qD3GNZpvyl2UjidXfWt4poHnYKLPyIiwi2Migb5vQ7k=; b=ayzPzKYTpLZSpZfl2W2FrIoZkYYOJx0GSfrAr/KZD1xyRSENAe75oBXhfhGyT1XqAl 5XgLEezTHS6JIlYc/TC8BC4u5JoZPBEmEXT1C+yy9lkcFL9c0atgEJgSwAbyYi005Fcf qPrMBeCD4/pv2bdwTIaobBRh7ECcxvQxHeHjGGs0yrhe5m2GWGUKqka7wIoTq1bSGuGW SDs5OJRB7BplrXUDE/ShMPp+NrWl8gGaXREfLQymQV7R7657s84gKGA+y11EeU/QRJUN tnzh4exlokuSCL8ikNT4IG6A/rY+1Cmk2SA2kfYrbwZmPsNSet5E1fnvXC/DbStfAapd yarw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FWWuL/jX; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f33-v6si9560157plb.585.2018.03.30.16.40.05; Fri, 30 Mar 2018 16:40:22 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=FWWuL/jX; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752769AbeC3Xiz (ORCPT + 99 others); Fri, 30 Mar 2018 19:38:55 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:46245 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752384AbeC3Xiy (ORCPT ); Fri, 30 Mar 2018 19:38:54 -0400 Received: by mail-io0-f196.google.com with SMTP id q80so12398250ioi.13 for ; Fri, 30 Mar 2018 16:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qD3GNZpvyl2UjidXfWt4poHnYKLPyIiwi2Migb5vQ7k=; b=FWWuL/jXJiNhiYtDjooscO5LA4VvL+JphYSPr+FYC/ixr77RzzeML931Alas1Tkr32 Ui9litr5j/b4t6GPqUA1fpCRQC7pMbjh4Ylhq87UsU+HYE4oBVSynCOc7zWyNY6kn5yj EPk7QJAUSKqSgHGN+ra3V8fVhLBl/6QTKVw690DlLkUNgcNmZ6Gm2Df65rhWwB3LCsEv jzkgqUUY873rtuYQcVKjcBgoAQ4653NcJCKsi9gYbedvH6xtH6gPzwNkeJxltm97Pfhe HhJvyWMsLJ9jOfWFpAPkSKxHAvDhZjSTLdCmNiJyl1nd3lNn+7MOWJ6BYmUA8i4GGlKq AH5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qD3GNZpvyl2UjidXfWt4poHnYKLPyIiwi2Migb5vQ7k=; b=S8tLppMpPUeaHxxtws9+A8ZStQNn9mBx+3OF3tzHvhH2SrF7ARrzlxhnmkyVxUe24r b0iMhCwrOrmGoqpvqV7P1x5q9wKocDFHpM5C2vrJUg+vHxDTxePnB3omicCYMCW0XjHR kR4lH7zR4mYGuU9dvrtmT30tNVrdW5p4PJ1qGSi+WCFRVEMQT1X3xreAZpBQM9jGyDVv h5GqNZsmAL9+FK1SeL9PlVmreiXm0yQfJKvbDPmoOcOohTmXdAPSBqmS6eGVGLJj36uf 4o/pOCmUeHlMSt9Wcmpr6YJ0Tsh6D2dq9I9m+Z2h0uyhdMMkyP6zvnMU6YV+Jtm+o0sp ddrg== X-Gm-Message-State: AElRT7GtAF2Pf14L90cAtk5LPXadFTouGKRRbCtGAleGvBVbEt7knjXo QTsj1uxIVcaOERhhA548NIg5t4gayolThn8fBvfsZQ== X-Received: by 10.107.58.134 with SMTP id h128mr831436ioa.299.1522453133375; Fri, 30 Mar 2018 16:38:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.11.158 with HTTP; Fri, 30 Mar 2018 16:38:52 -0700 (PDT) In-Reply-To: <20180330174209.4cb77003@gandalf.local.home> References: <1522320104-6573-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20180330102038.2378925b@gandalf.local.home> <20180330205356.GA13332@bombadil.infradead.org> <20180330173031.257a491a@gandalf.local.home> <20180330174209.4cb77003@gandalf.local.home> From: Joel Fernandes Date: Fri, 30 Mar 2018 16:38:52 -0700 Message-ID: Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem To: Steven Rostedt Cc: Matthew Wilcox , Zhaoyang Huang , Ingo Molnar , LKML , kernel-patch-test@lists.linaro.org, Andrew Morton , Michal Hocko , "open list:MEMORY MANAGEMENT" , Vlastimil Babka , Michal Hocko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steven, On Fri, Mar 30, 2018 at 2:42 PM, Steven Rostedt wrote: > On Fri, 30 Mar 2018 17:30:31 -0400 > Steven Rostedt wrote: > >> I'll take a look at si_mem_available() that Joel suggested and see if >> we can make that work. > > Wow, this appears to work great! Joel and Zhaoyang, can you test this? > > -- Steve > > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c > index a2fd3893cc02..32a803626ee2 100644 > --- a/kernel/trace/ring_buffer.c > +++ b/kernel/trace/ring_buffer.c > @@ -1164,6 +1164,11 @@ static int __rb_allocate_pages(long nr_pages, struct list_head *pages, int cpu) > struct buffer_page *bpage, *tmp; > long i; > > + /* Check if the available memory is there first */ > + i = si_mem_available(); > + if (i < nr_pages) Does it make sense to add a small margin here so that after ftrace finishes allocating, we still have some memory left for the system? But then then we have to define a magic number :-| > + return -ENOMEM; > + I tested in Qemu with 1GB memory, I am always able to get it to fail allocation even without this patch without causing an OOM. Maybe I am not running enough allocations in parallel or something :) The patch you shared using si_mem_available is working since I'm able to allocate till the end without a page allocation failure: bash-4.3# echo 237800 > /d/tracing/buffer_size_kb bash: echo: write error: Cannot allocate memory bash-4.3# echo 237700 > /d/tracing/buffer_size_kb bash-4.3# free -m total used free shared buffers Mem: 985 977 7 10 0 -/+ buffers: 977 7 Swap: 0 0 0 bash-4.3# I think this patch is still good to have, since IMO we should not go and get page allocation failure (even if its a non-OOM) and subsequent stack dump from mm's allocator, if we can avoid it. Tested-by: Joel Fernandes thanks, - Joel