linux-kernel - Re: [PATCH v9 2/3]: perf record: enable asynchronous trace writing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Oct 2018 14:50:01 +0300
From:   Alexey Budankov <alexey.budankov@...ux.intel.com>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        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 v9 2/3]: perf record: enable asynchronous trace writing

Hi,

On 05.10.2018 13:55, Namhyung Kim wrote:
<SNIP>
> On Fri, Oct 05, 2018 at 12:39:10PM +0300, Alexey Budankov wrote:
<SNIP>
>>
>> It still have to adjust the file pos thru lseek() prior leaving 
>> record__aio_pushfn() so space in trace file would be pre-allocated for 
>> enqueued record and file pos be moved beyond the record data, 
>> possibly for the next record.
> 
> For that purpose, isn't it better calling ftruncate() with a
> reasonable batch size to reduce number of syscalls?
> 

According to docs [1] ftruncate() does not advance file pos 
which is essential here.

> 
<SNIP>
>> Well, if it has AIO symbols + opts.nr_cblocks exposed unconditionally of 
>> HAVE_AIO_SUPPORT, but keeps the symbols implementation under the define, then
>> as far aio-cblocks option is not exposed thru command line, we end up in
>> whole bunch of symbols referenced under the else branch that, after all, 
>> can cause Perf binary size increase, which is, probably, worth avoiding.
> 
> I think it's ok as long as they're empty.

Well, the both designs are possible and acceptable.
The only thing that matters here is contradictive requests from other reviewing folks. 
Let me share the version without dummy functions so 
we could jointly decide how to proceed from there. 
Ok?

Thanks,
Alexey

[1] http://man7.org/linux/man-pages/man2/ftruncate.2.html