Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932249AbaJ3IoM (ORCPT ); Thu, 30 Oct 2014 04:44:12 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:58001 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758159AbaJ3IoK (ORCPT ); Thu, 30 Oct 2014 04:44:10 -0400 Date: Thu, 30 Oct 2014 09:43:59 +0100 From: Peter Zijlstra To: Alexander Shishkin Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Robert Richter , Frederic Weisbecker , Mike Galbraith , Paul Mackerras , Stephane Eranian , Andi Kleen , kan.liang@intel.com, adrian.hunter@intel.com, acme@infradead.org Subject: Re: [PATCH v5 18/20] perf: Allocate ring buffers for inherited per-task kernel events Message-ID: <20141030084359.GD23531@worktop.programming.kicks-ass.net> References: <1413207948-28202-1-git-send-email-alexander.shishkin@linux.intel.com> <1413207948-28202-19-git-send-email-alexander.shishkin@linux.intel.com> <20141023123855.GC12706@worktop.programming.kicks-ass.net> <87egtx3o95.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87egtx3o95.fsf@ashishki-desk.ger.corp.intel.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 24, 2014 at 10:44:54AM +0300, Alexander Shishkin wrote: > Peter Zijlstra writes: > > > On Mon, Oct 13, 2014 at 04:45:46PM +0300, Alexander Shishkin wrote: > >> Normally, per-task events can't be inherited parents' ring buffers to > >> avoid multiple events contending for the same buffer. And since buffer > >> allocation is typically done by the userspace consumer, there is no > >> practical interface to allocate new buffers for inherited counters. > >> > >> However, for kernel users we can allocate new buffers for inherited > >> events as soon as they are created (and also reap them on event > >> destruction). This pattern has a number of use cases, such as event > >> sample annotation and process core dump annotation. > >> > >> When a new event is inherited from a per-task kernel event that has a > >> ring buffer, allocate a new buffer for this event so that data from the > >> child task is collected and can later be retrieved for sample annotation > >> or core dump inclusion. This ring buffer is released when the event is > >> freed, for example, when the child task exits. > >> > > > > This causes a pinned memory explosion, not at all nice that. > > > > I think I see why and all, but it would be ever so good to not have to > > allocate so much memory. > > Are there any controls we could use to limit such memory usage? I'd say the same limit we're already accounting the mmap()s against. But the question is; what do we do when we run out? Will we fail clone()? That might 'surprise' quite a few people, that their application won't work when profiled. In any case, lets focus on the other parts of this work and delay this feature till later. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/