Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp904972pxb; Thu, 30 Sep 2021 21:41:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJys6+HfUhRaIvyOXwLSMOciEMMp37IYgGcYgRRulK6g5tFXg64hpuICg6MAwsyTdu+3GWNE X-Received: by 2002:a17:90a:6c97:: with SMTP id y23mr10874031pjj.117.1633063308866; Thu, 30 Sep 2021 21:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633063308; cv=none; d=google.com; s=arc-20160816; b=yBUrMP0HHgdxtxLK0vR9ztBdnIJQQ14uXkbii8GiB2yx5INSp0/olYncBevRCWKYqo fvHRggAxPjMZoD+CIPQ7n3O5QbzNrWPA0iq167GdDbKAMBL7BZ0ZeH5nZXE12ffiKpvA lFKmBUDa0fVVlMRatSrtfGWlM7ZpDb+NjCuLTBv2WYn1iTCgMMKQpz7OooZJx9OPX4JA r2enbg0Nxkh6+IzIh0GSKgyRhsDjk8PxILcIViLL+OvY26paCic8zIkDBAj1kDXu5iAF X5A3dt7fxn3dihoRUt9vVBRbY5gxTgq2EufStiCcBlMkkaMyH0hcdFwMP2TCpZumfdPw SYmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=LxWcNAidJqvsts3e+kBmUje9YZwZdZI0t8TtPZ9wWhM=; b=paQeC2N/EUEbE7D01tQiO1Gr7jnKQU9o7UHlsWRcIP3ZjcL85tpBGCpyNJb9Z8fjK+ Twqxt5HgvrNm0Z9W4aVXegMmABtr4HcV5zf/QFaB+oblkJlZC2+NH8DUj++cRQtE1N7t qbQRRQhwCQA3vftg0pocYDNaWt6mRBqdBsahZRvxStnGlvSQtAbVwzvLJmnKVgLtWWyp F1lPIaIDeEEvTrxsKsyu2DYuGIDRjgZMg0TgupKl1vT5HAV7ccb1n5IOwyznxt60zuHL mc63ObJKWqPvL4DJ0NepZZdbzHNSSvLELwXaXeWJDDleG2Vy8OWqnNcczixyHCNfIBAp kdsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si5988763pfg.174.2021.09.30.21.41.27; Thu, 30 Sep 2021 21:41:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237015AbhJAElI (ORCPT + 99 others); Fri, 1 Oct 2021 00:41:08 -0400 Received: from foss.arm.com ([217.140.110.172]:34596 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230477AbhJAElH (ORCPT ); Fri, 1 Oct 2021 00:41:07 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DBE9C106F; Thu, 30 Sep 2021 21:39:23 -0700 (PDT) Received: from [10.163.74.5] (unknown [10.163.74.5]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B33F3F70D; Thu, 30 Sep 2021 21:39:19 -0700 (PDT) Subject: Re: [PATCH v2 14/17] coresight: trbe: Make sure we have enough space To: Suzuki K Poulose , linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, maz@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, james.morse@arm.com, leo.yan@linaro.org, mike.leach@linaro.org, mathieu.poirier@linaro.org, will@kernel.org, lcherian@marvell.com, coresight@lists.linaro.org References: <20210921134121.2423546-1-suzuki.poulose@arm.com> <20210921134121.2423546-15-suzuki.poulose@arm.com> <60e75e7b-4a04-03d4-c861-88dd5fadef99@arm.com> From: Anshuman Khandual Message-ID: <79877977-16ec-7508-0870-d2f6ee8899e5@arm.com> Date: Fri, 1 Oct 2021 10:10:26 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/22/21 3:46 PM, Suzuki K Poulose wrote: > On 22/09/2021 10:58, Anshuman Khandual wrote: >> >> >> On 9/21/21 7:11 PM, Suzuki K Poulose wrote: >>> The TRBE driver makes sure that there is enough space for a meaningful >>> run, otherwise pads the given space and restarts the offset calculation >>> once. But there is no guarantee that we may find space or hit "no space". >> >> So what happens currently when it neither finds the required minimum buffer >> space for a meaningful run nor does it hit the "no space" scenario ? > > It tries once today and assumes that it will either hit : > >  - No space >    OR >  - Enough space > > which is reasonable, given the minimum space needed is a few bytes. > But this may no longer be true with other erratum workaround. Okay. > >> >>> Make sure that we repeat the step until, either : >>>    - We have the minimum space >>>     OR >>>    - There is NO space at all. >>> >>> Cc: Anshuman Khandual >>> Cc: Mathieu Poirier >>> Cc: Mike Leach >>> Cc: Leo Yan >>> Signed-off-by: Suzuki K Poulose >>> --- >>>   drivers/hwtracing/coresight/coresight-trbe.c | 6 +++++- >>>   1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c >>> index 3373f4e2183b..02f9e00e2091 100644 >>> --- a/drivers/hwtracing/coresight/coresight-trbe.c >>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c >>> @@ -451,10 +451,14 @@ static unsigned long trbe_normal_offset(struct perf_output_handle *handle) >>>        * If the head is too close to the limit and we don't >>>        * have space for a meaningful run, we rather pad it >>>        * and start fresh. >>> +     * >>> +     * We might have to do this more than once to make sure >>> +     * we have enough required space. >> >> OR no space at all, as explained in the commit message. >> Hence this comment needs an update. >> >>>        */ >>> -    if (limit && ((limit - head) < trbe_min_trace_buf_size(handle))) { >>> +    while (limit && ((limit - head) < trbe_min_trace_buf_size(handle))) { >>>           trbe_pad_buf(handle, limit - head); >>>           limit = __trbe_normal_offset(handle); >>> +        head = PERF_IDX2OFF(handle->head, buf); >> >> Should the loop be bound with a retry limit as well ? > > No. We will eventually hit No-space as we keep on padding > the buffer. Got it.