From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755256AbbCBQqZ (ORCPT ); Mon, 2 Mar 2015 11:46:25 -0500 Received: from mga02.intel.com ([134.134.136.20]:28541 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754259AbbCBQqY (ORCPT ); Mon, 2 Mar 2015 11:46:24 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,676,1418112000"; d="scan'208";a="673954359" Message-ID: <1425314765.20819.7.camel@picadillo> Subject: Re: [PATCH 07/15] mm: Add ___GFP_NOTRACE From: Tom Zanussi To: Steven Rostedt Cc: masami.hiramatsu.pt@hitachi.com, namhyung@kernel.org, andi@firstfloor.org, ast@plumgrid.com, linux-kernel@vger.kernel.org Date: Mon, 02 Mar 2015 10:46:05 -0600 In-Reply-To: <20150302113701.2171bdd5@gandalf.local.home> References: <93c67b74d54ffbb3658f0d69865bfb3ad5133a27.1425310176.git.tom.zanussi@linux.intel.com> <20150302113701.2171bdd5@gandalf.local.home> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2015-03-02 at 11:37 -0500, Steven Rostedt wrote: > On Mon, 2 Mar 2015 10:01:00 -0600 > Tom Zanussi wrote: > > > Add a gfp flag that allows kmalloc() et al to be used in tracing > > functions. > > > > The problem with using kmalloc for tracing is that the tracing > > subsystem should be able to trace kmalloc itself, which it can't do > > directly because of paths like kmalloc()->trace_kmalloc()->kmalloc() > > or kmalloc()->trace_mm_page_alloc()->kmalloc(). > > This part I don't like at all. Why can't the memory be preallocated > when the hist is created (the echo 'hist:...')? > Yeah, I didn't like it either. My original version did exactly what you suggest and preallocated an array of entries to 'allocate' from in order to avoid the problem. But I wanted to attempt to use the bpf_map directly, which already uses kmalloc internally. My fallback in case this wouldn't fly, which it obviously won't, would be to add an option to have the bpf_map code preallocate a maximum number of entries or pass in a client-owned array for the purpose. I'll do that if I don't hear any better ideas.. Tom > kmalloc must never be called from any tracepoint callback. > > This change is currently a showstopper. > > -- Steve > > > > > > With this flag, tracing code could use a special version of kmalloc() > > that sets __GFP_NOTRACE on every allocation it does, while leaving the > > normal kmalloc() path untouched. > > > > This would allow any tracepoint in the kmalloc path to be avoided via > > DEFINE_EVENT_CONDITION() redefinitions of those events, which check > > for ___GFP_NOTRACE immediately in their execution and break if set, > > thereby avoiding the recursion. > >