From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753716AbdJMUHF (ORCPT ); Fri, 13 Oct 2017 16:07:05 -0400 Received: from mail-wr0-f178.google.com ([209.85.128.178]:44558 "EHLO mail-wr0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753613AbdJMUHC (ORCPT ); Fri, 13 Oct 2017 16:07:02 -0400 X-Google-Smtp-Source: AOwi7QBp06bA6Hbc7cEE07hP6wQ2IaiWOGpAkS+fx0t2BkteBvtu7vYfxXaw7/yijs7wY/ffQPJXDw== Date: Fri, 13 Oct 2017 22:06:58 +0200 From: Ingo Molnar To: Arnaldo Carvalho de Melo Cc: kan.liang@intel.com, peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, jolsa@kernel.org, wangnan0@huawei.com, hekuang@huawei.com, namhyung@kernel.org, alexander.shishkin@linux.intel.com, adrian.hunter@intel.com, ak@linux.intel.com Subject: Re: [PATCH 3/4] perf record: event synthesization multithreading support Message-ID: <20171013200658.gokyihds32ftwgy5@gmail.com> References: <1507903767-293944-1-git-send-email-kan.liang@intel.com> <1507903767-293944-4-git-send-email-kan.liang@intel.com> <20171013143856.GP3503@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171013143856.GP3503@kernel.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnaldo Carvalho de Melo wrote: > Em Fri, Oct 13, 2017 at 07:09:26AM -0700, kan.liang@intel.com escreveu: > > From: Kan Liang > > > > The process function process_synthesized_event writes the process > > result to perf.data, which is not multithreading friendly. > > > > Realloc buffer for each thread to temporarily keep the processing > > result. Write them to the perf.data at the end of event synthesization. > > The new method doesn't impact the final result, because > > - The order of the synthesized event is not important. > > - The number of synthesized event is limited. Usually, it only needs > > hundreds of Kilobyte to store all the synthesized event. > > It's unlikly failed because of lack of memory. > > Why not write to a per cpu file and then at the end merge them? Leave > the memory management to the kernel, i.e. in most cases you may even not > end up touching the disk, when memory is plentiful, just rewind the per > event files and go on dumping to the main perf.data file. > > At some point we may just don't do this merging, and keep per cpu files > all the way to perf report, etc. This would be a first foray into > that... Yeah, that sounds like a really good zero-copy recording scheme, and I bet it would scale like a crazed bat out of hell! Thanks, Ingo