linux-kernel - Re: [PATCH 1/2] perf sched: Prefer sched

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200810162228.GB4527@kernel.org>
Date:   Mon, 10 Aug 2020 13:22:28 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     David Ahern <dsahern@...il.com>
Cc:     David Ahern <dsahern@...nel.org>, namhyung@...nel.org,
        linux-kernel@...r.kernel.org, jolsa@...nel.org
Subject: Re: [PATCH 1/2] perf sched: Prefer sched_waking event when it exists

Em Fri, Aug 07, 2020 at 01:50:47PM -0600, David Ahern escreveu:
> On 8/7/20 1:43 PM, Arnaldo Carvalho de Melo wrote:
> >> @@ -2958,9 +2967,10 @@ static int timehist_check_attr(struct perf_sched *sched,
> >>  
> >>  static int perf_sched__timehist(struct perf_sched *sched)
> >>  {
> >> -	const struct evsel_str_handler handlers[] = {
> >> +	struct evsel_str_handler handlers[] = {
> >>  		{ "sched:sched_switch",       timehist_sched_switch_event, },
> >>  		{ "sched:sched_wakeup",	      timehist_sched_wakeup_event, },
> >> +		{ "sched:sched_waking",       timehist_sched_wakeup_event, },
> >>  		{ "sched:sched_wakeup_new",   timehist_sched_wakeup_event, },
> >>  	};
> >>  	const struct evsel_str_handler migrate_handlers[] = {
> >> @@ -3018,6 +3028,11 @@ static int perf_sched__timehist(struct perf_sched *sched)
> >>  
> >>  	setup_pager();
> >>  
> >> +	/* prefer sched_waking if it is captured */
> >> +	if (perf_evlist__find_tracepoint_by_name(session->evlist,
> >> +						  "sched:sched_waking"))
> >> +		handlers[1].handler = timehist_sched_wakeup_ignore;
> >> +
> > 
> > 
> > ouch, can't we figure out if its present and then don't ask for the
> > wakeup one to be recorded?
> > 
> 
> This is the analysis side. If someone recorded with sched:* we do not
> want to analyze both sched_wakeup and sched_waking. Rather, it should
> prefer the latter and ignore the former.

Right you are, thans for the explanation, I should've noticed that :)

- Arnaldoi