All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>,
	Leo Yan <leo.yan@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] coresight: tmc-etr: Speed up for bounce buffer in flat mode
Date: Tue, 14 Sep 2021 07:00:24 +0100	[thread overview]
Message-ID: <2a2ba78b-5a03-ccf3-00d8-b0e1b02dc293@arm.com> (raw)
In-Reply-To: <20210913175635.GA1676953@p14s>

On 13/09/2021 18:56, Mathieu Poirier wrote:
> On Sun, Sep 05, 2021 at 11:21:44AM +0800, Leo Yan wrote:
>> The AUX bounce buffer is allocated with API dma_alloc_coherent(), in the
>> low level's architecture code, e.g. for Arm64, it maps the memory with
>> the attribution "Normal non-cacheable"; this can be concluded from the
>> definition for pgprot_dmacoherent() in arch/arm64/include/asm/pgtable.h.
>>
>> Later when access the AUX bounce buffer, since the memory mapping is
>> non-cacheable, it's low efficiency due to every load instruction must
>> reach out DRAM.
>>
>> This patch changes to allocate pages with dma_alloc_noncoherent(), the
>> driver can access the memory via cacheable mapping; therefore, load
>> instructions can fetch data from cache lines rather than always read
>> data from DRAM, the driver can boost memory performance.  After using
>> the cacheable mapping, the driver uses dma_sync_single_for_cpu() to
>> invalidate cacheline prior to read bounce buffer so can avoid read stale
>> trace data.
>>
>> By measurement the duration for function tmc_update_etr_buffer() with
>> ftrace function_graph tracer, it shows the performance significant
>> improvement for copying 4MiB data from bounce buffer:
>>
>>    # echo tmc_etr_get_data_flat_buf > set_graph_notrace // avoid noise
>>    # echo tmc_update_etr_buffer > set_graph_function
>>    # echo function_graph > current_tracer
>>
>>    before:
>>
>>    # CPU  DURATION                  FUNCTION CALLS
>>    # |     |   |                     |   |   |   |
>>    2)               |    tmc_update_etr_buffer() {
>>    ...
>>    2) # 8148.320 us |    }
>>
>>    after:
>>
>>    # CPU  DURATION                  FUNCTION CALLS
>>    # |     |   |                     |   |   |   |
>>    2)               |  tmc_update_etr_buffer() {
>>    ...
>>    2) # 2525.420 us |  }
>>
>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>
>> Changes from v3:
>> Refined change to use dma_alloc_noncoherent()/dma_free_noncoherent()
>> (Robin Murphy);
>> Retested functionality and performance on Juno-r2 board.
>>
>> Changes from v2:
>> Sync the entire buffer in one go when the tracing is wrap around
>> (Suzuki);
>> Add Suzuki's review tage.
>>
>>   .../hwtracing/coresight/coresight-tmc-etr.c   | 26 ++++++++++++++++---
>>   1 file changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> index acdb59e0e661..a049b525a274 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> @@ -609,8 +609,9 @@ static int tmc_etr_alloc_flat_buf(struct tmc_drvdata *drvdata,
>>   	if (!flat_buf)
>>   		return -ENOMEM;
>>   
>> -	flat_buf->vaddr = dma_alloc_coherent(real_dev, etr_buf->size,
>> -					     &flat_buf->daddr, GFP_KERNEL);
>> +	flat_buf->vaddr = dma_alloc_noncoherent(real_dev, etr_buf->size,
>> +						&flat_buf->daddr,
>> +						DMA_FROM_DEVICE, GFP_KERNEL);
> 
> Suzuki and Robin - are you guys good with this new revision?

Yes, fine by me.

Suzuki

WARNING: multiple messages have this Message-ID (diff)
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>,
	Leo Yan <leo.yan@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] coresight: tmc-etr: Speed up for bounce buffer in flat mode
Date: Tue, 14 Sep 2021 07:00:24 +0100	[thread overview]
Message-ID: <2a2ba78b-5a03-ccf3-00d8-b0e1b02dc293@arm.com> (raw)
In-Reply-To: <20210913175635.GA1676953@p14s>

On 13/09/2021 18:56, Mathieu Poirier wrote:
> On Sun, Sep 05, 2021 at 11:21:44AM +0800, Leo Yan wrote:
>> The AUX bounce buffer is allocated with API dma_alloc_coherent(), in the
>> low level's architecture code, e.g. for Arm64, it maps the memory with
>> the attribution "Normal non-cacheable"; this can be concluded from the
>> definition for pgprot_dmacoherent() in arch/arm64/include/asm/pgtable.h.
>>
>> Later when access the AUX bounce buffer, since the memory mapping is
>> non-cacheable, it's low efficiency due to every load instruction must
>> reach out DRAM.
>>
>> This patch changes to allocate pages with dma_alloc_noncoherent(), the
>> driver can access the memory via cacheable mapping; therefore, load
>> instructions can fetch data from cache lines rather than always read
>> data from DRAM, the driver can boost memory performance.  After using
>> the cacheable mapping, the driver uses dma_sync_single_for_cpu() to
>> invalidate cacheline prior to read bounce buffer so can avoid read stale
>> trace data.
>>
>> By measurement the duration for function tmc_update_etr_buffer() with
>> ftrace function_graph tracer, it shows the performance significant
>> improvement for copying 4MiB data from bounce buffer:
>>
>>    # echo tmc_etr_get_data_flat_buf > set_graph_notrace // avoid noise
>>    # echo tmc_update_etr_buffer > set_graph_function
>>    # echo function_graph > current_tracer
>>
>>    before:
>>
>>    # CPU  DURATION                  FUNCTION CALLS
>>    # |     |   |                     |   |   |   |
>>    2)               |    tmc_update_etr_buffer() {
>>    ...
>>    2) # 8148.320 us |    }
>>
>>    after:
>>
>>    # CPU  DURATION                  FUNCTION CALLS
>>    # |     |   |                     |   |   |   |
>>    2)               |  tmc_update_etr_buffer() {
>>    ...
>>    2) # 2525.420 us |  }
>>
>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>
>> Changes from v3:
>> Refined change to use dma_alloc_noncoherent()/dma_free_noncoherent()
>> (Robin Murphy);
>> Retested functionality and performance on Juno-r2 board.
>>
>> Changes from v2:
>> Sync the entire buffer in one go when the tracing is wrap around
>> (Suzuki);
>> Add Suzuki's review tage.
>>
>>   .../hwtracing/coresight/coresight-tmc-etr.c   | 26 ++++++++++++++++---
>>   1 file changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> index acdb59e0e661..a049b525a274 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
>> @@ -609,8 +609,9 @@ static int tmc_etr_alloc_flat_buf(struct tmc_drvdata *drvdata,
>>   	if (!flat_buf)
>>   		return -ENOMEM;
>>   
>> -	flat_buf->vaddr = dma_alloc_coherent(real_dev, etr_buf->size,
>> -					     &flat_buf->daddr, GFP_KERNEL);
>> +	flat_buf->vaddr = dma_alloc_noncoherent(real_dev, etr_buf->size,
>> +						&flat_buf->daddr,
>> +						DMA_FROM_DEVICE, GFP_KERNEL);
> 
> Suzuki and Robin - are you guys good with this new revision?

Yes, fine by me.

Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-09-14  6:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-05  3:21 [PATCH v4] coresight: tmc-etr: Speed up for bounce buffer in flat mode Leo Yan
2021-09-05  3:21 ` Leo Yan
2021-09-13 17:56 ` Mathieu Poirier
2021-09-13 17:56   ` Mathieu Poirier
2021-09-14  6:00   ` Suzuki K Poulose [this message]
2021-09-14  6:00     ` Suzuki K Poulose
2021-09-14 15:22 ` Mathieu Poirier
2021-09-14 15:22   ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a2ba78b-5a03-ccf3-00d8-b0e1b02dc293@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=coresight@lists.linaro.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=robin.murphy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.