From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934432AbdKBUg3 (ORCPT ); Thu, 2 Nov 2017 16:36:29 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:44701 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934115AbdKBUg1 (ORCPT ); Thu, 2 Nov 2017 16:36:27 -0400 X-Google-Smtp-Source: ABhQp+QETO2x7Rzkv69UBsw08SnaIUi1VFeRuyTOkGrHO1WxwoZCZGGWk9gBW1FSFKI0pZJgvcLtuw== Date: Thu, 2 Nov 2017 14:36:23 -0600 From: Mathieu Poirier To: Suzuki K Poulose Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, rob.walker@arm.com, mike.leach@linaro.org, coresight@lists.linaro.org Subject: Re: [PATCH 13/17] coresight etr: Do not clean ETR trace buffer Message-ID: <20171102203623.GE23320@xps15> References: <20171019171553.24056-1-suzuki.poulose@arm.com> <20171019171553.24056-14-suzuki.poulose@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171019171553.24056-14-suzuki.poulose@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > Get rid of this step, if someone wants to debug, they can always > add it as and when needed. > > Cc: Mathieu Poirier > Signed-off-by: Suzuki K Poulose > --- > drivers/hwtracing/coresight/coresight-tmc-etr.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c > index 31353fc34b53..849684f85443 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c > @@ -971,8 +971,6 @@ static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata, > return; > > drvdata->etr_buf = etr_buf; > - /* Zero out the memory to help with debug */ > - memset(etr_buf->vaddr, 0, etr_buf->size); I agree, this can be costly when dealing with large areas of memory. > > CS_UNLOCK(drvdata->base); > > @@ -1267,9 +1265,8 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata) > if (drvdata->mode == CS_MODE_SYSFS) { > /* > * The trace run will continue with the same allocated trace > - * buffer. The trace buffer is cleared in tmc_etr_enable_hw(), > - * so we don't have to explicitly clear it. Also, since the > - * tracer is still enabled drvdata::buf can't be NULL. > + * buffer. Since the tracer is still enabled drvdata::buf can't > + * be NULL. > */ > tmc_etr_enable_hw(drvdata, drvdata->sysfs_buf); > } else { > -- > 2.13.6 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: mathieu.poirier@linaro.org (Mathieu Poirier) Date: Thu, 2 Nov 2017 14:36:23 -0600 Subject: [PATCH 13/17] coresight etr: Do not clean ETR trace buffer In-Reply-To: <20171019171553.24056-14-suzuki.poulose@arm.com> References: <20171019171553.24056-1-suzuki.poulose@arm.com> <20171019171553.24056-14-suzuki.poulose@arm.com> Message-ID: <20171102203623.GE23320@xps15> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. > Get rid of this step, if someone wants to debug, they can always > add it as and when needed. > > Cc: Mathieu Poirier > Signed-off-by: Suzuki K Poulose > --- > drivers/hwtracing/coresight/coresight-tmc-etr.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c > index 31353fc34b53..849684f85443 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c > @@ -971,8 +971,6 @@ static void tmc_etr_enable_hw(struct tmc_drvdata *drvdata, > return; > > drvdata->etr_buf = etr_buf; > - /* Zero out the memory to help with debug */ > - memset(etr_buf->vaddr, 0, etr_buf->size); I agree, this can be costly when dealing with large areas of memory. > > CS_UNLOCK(drvdata->base); > > @@ -1267,9 +1265,8 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata) > if (drvdata->mode == CS_MODE_SYSFS) { > /* > * The trace run will continue with the same allocated trace > - * buffer. The trace buffer is cleared in tmc_etr_enable_hw(), > - * so we don't have to explicitly clear it. Also, since the > - * tracer is still enabled drvdata::buf can't be NULL. > + * buffer. Since the tracer is still enabled drvdata::buf can't > + * be NULL. > */ > tmc_etr_enable_hw(drvdata, drvdata->sysfs_buf); > } else { > -- > 2.13.6 >