From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751910AbdJRREK (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Oct 2017 13:04:10 -0400
Received: from mail-wm0-f66.google.com ([74.125.82.66]:54782 "EHLO
        mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751577AbdJRREI (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Oct 2017 13:04:08 -0400
X-Google-Smtp-Source: ABhQp+S+rWt0es0HEJ40UwlZfBGbyuHRzaCT0CdKoBxxJpAyIdu5HI6jlfMXlhfcTS7ao7QH+gPeXQ==
Date: Wed, 18 Oct 2017 19:04:04 +0200
From: Ingo Molnar <mingo@kernel.org>
To: kan.liang@intel.com
Cc: acme@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org,
        peterz@infradead.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 V2 0/5] event synthesization multithreading for perf
 record
Message-ID: <20171018170404.nneblkkkmeqjtflp@gmail.com>
References: <1508336973-383492-1-git-send-email-kan.liang@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1508336973-383492-1-git-send-email-kan.liang@intel.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* kan.liang@intel.com <kan.liang@intel.com> wrote:

> From: Kan Liang <Kan.liang@intel.com>
> 
> The event synthesization multithreading is introduced in
> ("perf top optimization") https://lkml.org/lkml/2017/9/29/269
> But it was not enabled for perf record. Because the process function
> process_synthesized_event was not multithreading friendly.
> 
> The patch series temporarily stores the process result in per-thread file,
> which make the processing in parallel. Then it dumps the file one by one to
> the perf.data at the end of event synthesization.
> 
> The source code is also available at
> https://github.com/kliang2/perf.git perf_record_opt
> 
> Usually, the event synthesization only happens once on either start or end.
> With the snapshotting code, we synthesize events multiple times, once per
> each new perf.data file. Both of the cases are verified.
> 
> Here are the latency test result on Knights Mill and Skylake server
> 
> The workload is to compile Linux kernel as below
> "sudo nice make -j$(grep -c '^processor' /proc/cpuinfo)"
> Then, "sudo perf record -e cycles -a -- sleep 1"
> 
> The latency is the time cost of __machine__synthesize_threads or
> its multithreading replacement, record__multithread_synthesize.
> 
> - Latency on Knights Mill (272 CPUs)
> 
> Original(s)     With patch(s)   Speedup
> 12.74           5.54            2.3X
> 
> - Latency on Skylake server (192 CPUs)
> 
> Original(s)     With patch(s)   Speedup
> 0.36            0.25            1.47X

Btw., just as an interesting experiment, could you try to measure how it performs 
to create just the per-CPU files, and *not* dump them into a single file?

I.e. how much faster will it get if the serialization at the end is avoided?

Of course nothing can read such per-CPU files yet, so this is just for scalability 
measurement.

Thanks,

	Ingo