mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yicong Yang <yangyicong@huawei.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
	<mathieu.poirier@linaro.org>, <jonathan.cameron@huawei.com>,
	<linux-kernel@vger.kernel.org>
Cc: <yangyicong@hisilicon.com>, <alexander.shishkin@linux.intel.com>,
	<helgaas@kernel.org>, <linux-pci@vger.kernel.org>,
	<prime.zeng@hisilicon.com>, <linuxarm@huawei.com>,
	<hejunhao3@huawei.com>
Subject: Re: [PATCH v2 3/5] hwtracing: hisi_ptt: Optimize the trace data committing
Date: Tue, 19 Sep 2023 21:19:41 +0800	[thread overview]
Message-ID: <fd62aa39-78d7-a6c5-7782-8214256ee51b@huawei.com> (raw)
In-Reply-To: <03da788f-584b-1be5-2cc3-70a9e57c11ba@arm.com>

On 2023/9/15 22:44, Suzuki K Poulose wrote:
> On 14/09/2023 12:22, Yicong Yang wrote:
>> From: Yicong Yang <yangyicong@hisilicon.com>
>>
>> Currently during the PTT trace, we'll only commit the data
>> to the perf core when its full, which means after 4 interrupts
>> and totally 16MiB data while the AUX buffer is 16MiB length.
>> Then the userspace gets notified and handle the data. The driver
>> cannot apply a new AUX buffer immediately until the committed data
>> are handled and there's enough room in the buffer again.
>>
>> This patch tries to optimize this by commit the data in every
>> interrupts in a 4MiB granularity. Then the userspace can have
>> enough time to consume the data and there's always enough room
>> in the AUX buffer.
> 
> Instead of always committing at 4M, could we not use the existing
> markers used by the handle->wakeup to decide if we should commit it ?
> 

Is it intended to avoid too much wakeups? I think the core will handle
the wakeup even if we commit the data in perf_aux_output_end().
For example, if the userspace buffer is 16MiB and the watermark is 8MiB,
we'll not wake up userspace after the first 4MiB committing.

4MiB mentioned in the commit is our current configuration: hardware
maintains 4 buffers and driver configure each one as 4MiB. Driver will
get interrupt if one buffer filled and then copy the data to the AUX
buffer. We restrict the AUX buffer to be at least 16MiB. Previous we'll
only commit the data if the resident space in the AUX buffer cannot
contain next 4MiB data, typically after copy 4 buffers to AUX buffer.
This is suboptimal because after committing there's no space in the
AUX buffer and driver needs to wait until userspace consumes the data.
So we optimize it in this patch to always commit the data to AUX
buffer in time to avoid waiting.

> 
> Suzuki
> 
>>
>> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
>> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>> ---
>>   drivers/hwtracing/ptt/hisi_ptt.c | 15 +++++++--------
>>   1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/hwtracing/ptt/hisi_ptt.c b/drivers/hwtracing/ptt/hisi_ptt.c
>> index 3041238a6e54..4f355df8da23 100644
>> --- a/drivers/hwtracing/ptt/hisi_ptt.c
>> +++ b/drivers/hwtracing/ptt/hisi_ptt.c
>> @@ -274,15 +274,14 @@ static int hisi_ptt_update_aux(struct hisi_ptt *hisi_ptt, int index, bool stop)
>>       buf->pos += size;
>>         /*
>> -     * Just commit the traced data if we're going to stop. Otherwise if the
>> -     * resident AUX buffer cannot contain the data of next trace buffer,
>> -     * apply a new one.
>> +     * Always commit the data to the AUX buffer in time to make sure
>> +     * userspace got enough time to consume the data.
>> +     *
>> +     * If we're not going to stop, apply a new one and check whether
>> +     * there's enough room for the next trace.
>>        */
>> -    if (stop) {
>> -        perf_aux_output_end(handle, buf->pos);
>> -    } else if (buf->length - buf->pos < HISI_PTT_TRACE_BUF_SIZE) {
>> -        perf_aux_output_end(handle, buf->pos);
>> -
>> +    perf_aux_output_end(handle, size);
>> +    if (!stop) {
>>           buf = perf_aux_output_begin(handle, event);
>>           if (!buf)
>>               return -EINVAL;
> 
> 
> .

  reply	other threads:[~2023-09-19 13:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14 11:22 [PATCH v2 0/5] Several updates for PTT driver Yicong Yang
2023-09-14 11:22 ` [PATCH v2 1/5] hwtracing: hisi_ptt: Disable interrupt after trace end Yicong Yang
2023-09-14 11:22 ` [PATCH v2 2/5] hwtracing: hisi_ptt: Handle the interrupt in hardirq context Yicong Yang
2023-09-14 11:22 ` [PATCH v2 3/5] hwtracing: hisi_ptt: Optimize the trace data committing Yicong Yang
2023-09-15 14:44   ` Suzuki K Poulose
2023-09-19 13:19     ` Yicong Yang [this message]
2023-09-14 11:22 ` [PATCH v2 4/5] hwtracing: hisi_ptt: Don't try to attach a task Yicong Yang
2023-09-14 11:22 ` [PATCH v2 5/5] hwtracing: hisi_ptt: Add dummy callback pmu::read() Yicong Yang
2023-09-15 12:53   ` Suzuki K Poulose
2023-09-19 13:03     ` Yicong Yang
2023-09-19 17:01       ` Suzuki K Poulose
2023-09-20  7:10         ` Yicong Yang

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=fd62aa39-78d7-a6c5-7782-8214256ee51b@huawei.com \
    --to=yangyicong@huawei.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=hejunhao3@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=prime.zeng@hisilicon.com \
    --cc=suzuki.poulose@arm.com \
    --cc=yangyicong@hisilicon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®