Message ID | 20230914112223.27165-4-yangyicong@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp280368vqi; Thu, 14 Sep 2023 04:35:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHCtEzEZ2j/vxbRX8kZyBl3B1OdDbPdaaeG3OLZGs//GHWyT8ba8jI7iTXF/0j1ecXqEhJ1 X-Received: by 2002:a17:902:6b09:b0:1c3:6e38:3940 with SMTP id o9-20020a1709026b0900b001c36e383940mr5195032plk.7.1694691308505; Thu, 14 Sep 2023 04:35:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694691308; cv=none; d=google.com; s=arc-20160816; b=tq5JJC+53O8T7PmOW0JZOHaYDGZwY6YrdfkOISeytJCsiNk5pbImkllFGyh+O89cq6 CDCUZfylYvAIJqALwHEbbIMyinGppml/G7aZD+4FsfuVazkiWJRM9ZQyii0lr4FszMFr GytVpJLqwJr10XwP27Hp9taXxrFtWhEZnXMHsYJqS5UvuLOgZyzjD1ptmt02iJAt/wSp kAKGsckVvgBMk8eHkv7bTODFgAEWZB6HZ3XYbmZOOL+bC1Wd46RlBllJ6Uz7qs6AX3/s e07k16HeIBaldMfAbIMGOVsV/8Gvo4tzs1kMZL5LzHDHZKqs+n3cxPuuJi7538C/HTqa 4DnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=d14QcFvdPTUcBgD3vyQiQ44onpEQEIa+7WNttuaPO+M=; fh=ko8w2iEBByNlWLnAg6bNI5pex73wZFG+4jwxERcD8TA=; b=nuz+NJOdGC2kR2KS6kmbfpd3LFqGE5PAy2roqCnl+JJSt512Em4iZ65bD9Ny7jOfsF 4/K4+B7cAhYEGATSYsTjkzOLW98fTaD9mk4G1sB2vFce+J7FzHLfryEjRiNX/c3rXfPZ h/5KGrZ8i/z2HGMYWMfdSmCNF9Jbnwa0ijMNPZRriTWtTJinODmkl5bSrBEeIEevxxw9 xxZm2mBlM1pv/3YoolHK2WJTkQfuK3W8xqB+yZmo2YvjCn9Iroth0p2znJupqCWNceqF FfpbuAKlnm5lcKwpIRQ8vTux8D/JrF6zpeb82bBjGivLje7Xyn7q+hgV9HtoYOBCyHPl +Tzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id u3-20020a170902e5c300b001bf5753e0ccsi1656757plf.119.2023.09.14.04.35.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 04:35:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id C3F6D8177E0C; Thu, 14 Sep 2023 04:26:09 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233717AbjINLZx (ORCPT <rfc822;chrisfriedt@gmail.com> + 35 others); Thu, 14 Sep 2023 07:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232845AbjINLZv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 07:25:51 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD86FA8; Thu, 14 Sep 2023 04:25:46 -0700 (PDT) Received: from canpemm500009.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4RmZgY17DLz1N83D; Thu, 14 Sep 2023 19:23:05 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 14 Sep 2023 19:25:02 +0800 From: Yicong Yang <yangyicong@huawei.com> To: <suzuki.poulose@arm.com>, <mathieu.poirier@linaro.org>, <jonathan.cameron@huawei.com>, <linux-kernel@vger.kernel.org> CC: <alexander.shishkin@linux.intel.com>, <helgaas@kernel.org>, <linux-pci@vger.kernel.org>, <prime.zeng@hisilicon.com>, <linuxarm@huawei.com>, <yangyicong@hisilicon.com>, <hejunhao3@huawei.com> Subject: [PATCH v2 3/5] hwtracing: hisi_ptt: Optimize the trace data committing Date: Thu, 14 Sep 2023 19:22:21 +0800 Message-ID: <20230914112223.27165-4-yangyicong@huawei.com> X-Mailer: git-send-email 2.31.0 In-Reply-To: <20230914112223.27165-1-yangyicong@huawei.com> References: <20230914112223.27165-1-yangyicong@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Thu, 14 Sep 2023 04:26:09 -0700 (PDT) X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777012633026967520 X-GMAIL-MSGID: 1777012633026967520 |
Series |
Several updates for PTT driver
|
|
Commit Message
Yicong Yang
Sept. 14, 2023, 11:22 a.m. UTC
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. 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(-)
Comments
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 ? 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;
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; > > > .
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;