From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756913AbdKGKh3 (ORCPT ); Tue, 7 Nov 2017 05:37:29 -0500 Received: from foss.arm.com ([217.140.101.70]:47422 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753881AbdKGKh0 (ORCPT ); Tue, 7 Nov 2017 05:37:26 -0500 Subject: Re: [PATCH 13/17] coresight etr: Do not clean ETR trace buffer To: Mathieu Poirier Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , rob.walker@arm.com, Mike Leach , coresight@lists.linaro.org References: <20171019171553.24056-1-suzuki.poulose@arm.com> <20171019171553.24056-14-suzuki.poulose@arm.com> <20171102203623.GE23320@xps15> From: Suzuki K Poulose Message-ID: <6897a1ae-eede-6f78-1d2f-4dfb26679162@arm.com> Date: Tue, 7 Nov 2017 10:37:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/11/17 20:17, Mathieu Poirier wrote: > On 3 November 2017 at 04:10, Suzuki K Poulose wrote: >> On 02/11/17 20:36, Mathieu Poirier wrote: >>> >>> On Thu, Oct 19, 2017 at 06:15:49PM +0100, Suzuki K Poulose wrote: >>>> >>>> We zero out the entire trace buffer used for ETR before it >>>> is enabled, for helping with debugging. Since we could be >>>> restoring a session in perf mode, this could destroy the data. >>> >>> >>> I'm not sure to follow you with "... restoring a session in perf mode >>> ...". >>> When operating from the perf interface all the memory allocated for a >>> session is >>> cleanup after, there is no re-using of memory as in sysFS. >> >> >> We could directly use the perf ring buffer for the ETR. In that case, the >> perf >> ring buffer could contain trace data collected from the previous "schedule" >> which the userspace hasn't collected yet. So, doing a memset here would >> destroy that data. > > I originally thought your comment was about re-using the memory from a > previous trace session, hence the confusion. Please rework your > changelog to include this clarification as I am sure other people can > be mislead. Sure, will do. Thanks Suzuki