linux-kernel - Re: [PATCH v2 08/15] perf record: write trace data into mmap trace files

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:   Mon, 26 Oct 2020 11:32:27 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Alexei Budankov <budankov.lore@...il.com>
Cc:     Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 08/15] perf record: write trace data into mmap trace
 files

On Mon, Oct 26, 2020 at 11:52:21AM +0300, Alexei Budankov wrote:
> 
> On 24.10.2020 18:44, Jiri Olsa wrote:
> > On Wed, Oct 21, 2020 at 07:02:56PM +0300, Alexey Budankov wrote:
> > 
> > SNIP
> > 
> >>  
> >>  	record__synthesize(rec, true);
> >> -	/* this will be recalculated during process_buildids() */
> >> -	rec->samples = 0;
> >>  
> >>  	if (!err) {
> >>  		if (!rec->timestamp_filename) {
> >> @@ -2680,9 +2709,12 @@ int cmd_record(int argc, const char **argv)
> >>  
> >>  	}
> >>  
> >> -	if (rec->opts.kcore)
> >> +	if (rec->opts.kcore || record__threads_enabled(rec))
> >>  		rec->data.is_dir = true;
> >>  
> >> +	if (record__threads_enabled(rec))
> >> +		rec->opts.affinity = PERF_AFFINITY_CPU;
> > 
> > so all the threads will pin to cpu and back before reading?
> 
> No, they will not back. Thread mask compares to mmap mask before
> read and the thread migrates if masks don't match. This happens
> once on the first mmap read. So explicit pinning can be avoided.

hum, is that right? the check in record__adjust_affinity
is checking global 'rec->affinity_mask', at lest I assume
it's still global ;-)

        if (rec->opts.affinity != PERF_AFFINITY_SYS &&
            !bitmap_equal(rec->affinity_mask.bits, map->affinity_mask.bits,
                          rec->affinity_mask.nbits)) {

I think this can never be equal if you have more than one map

when I check on sched_setaffinity syscalls:

  # perf trace -e syscalls:sys_enter_sched_setaffinity

while running record --threads, I see sched_setaffinity
calls all the time

jirka