[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f711022-41ec-275c-7f9f-a1f269b23b37@linux.intel.com>
Date: Fri, 12 Oct 2018 13:21:19 +0300
From: Alexey Budankov <alexey.budankov@...ux.intel.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>, Andi Kleen <ak@...ux.intel.com>,
linux-kernel <linux-kernel@...r.kernel.org>, kernel-team@....com
Subject: Re: [PATCH v13 3/3]: perf record: extend trace writing to multi AIO
Hi,
On 12.10.2018 12:49, Namhyung Kim wrote:
> Hi,
>
> On Thu, Oct 11, 2018 at 09:59:19PM +0300, Alexey Budankov wrote:
>>
<SNIP>
>> @@ -1882,8 +1913,8 @@ static struct option __record_options[] = {
>> OPT_BOOLEAN(0, "dry-run", &dry_run,
>> "Parse options then exit"),
>> #ifdef HAVE_AIO_SUPPORT
>> - OPT_CALLBACK_NOOPT(0, "aio", &record.opts,
>> - NULL, "Enable asynchronous trace writing mode",
>> + OPT_CALLBACK(0, "aio", &record.opts,
>> + "n", "Use <n> control blocks in asynchronous trace writing mode (default: 1, max: 4)",
>
> One question. It seems you used a very large N in your test result.
> Why did you limit it to 4 here? Is it something different? Maybe
> you'd better making it a macro constant for future changes..
Yes, it's less than values used during metrics measurements.
There is still no good rationale behind top border value
because currently it is a kind of implementation detail.
Defining as a macro makes sense for easier source code management.
Thanks,
Alexey
>
> Otherwise looks good to me. For the 3 patches
>
> Acked-by: Namhyung Kim <namhyung@...nel.org>
>
> Thanks,
> Namhyung
Powered by blists - more mailing lists