linux-kernel - Re: [PATCH 2/2] kernel/events: Add option to enable counting sideband events in wakeup

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]

Message-Id: <20170713145519.ag64gkid7ljm3jzl@naverao1-tp.localdomain>
Date:   Thu, 13 Jul 2017 20:25:19 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] kernel/events: Add option to enable counting
 sideband events in wakeup_events

On 2017/07/12 01:48PM, Peter Zijlstra wrote:
> On Mon, Jun 19, 2017 at 08:01:08PM +0530, Naveen N. Rao wrote:
> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> > index 4e7c728569a8..f43a6081141f 100644
> > --- a/kernel/events/ring_buffer.c
> > +++ b/kernel/events/ring_buffer.c
> > @@ -197,6 +197,19 @@ __perf_output_begin(struct perf_output_handle *handle,
> >  	 * none of the data stores below can be lifted up by the compiler.
> >  	 */
> >  
> > +	if (event->attr.count_sb_events && !event->attr.watermark) {
> > +		int wakeup_events = event->attr.wakeup_events;
> > +
> > +		if (wakeup_events) {
> > +			int events = local_inc_return(&rb->events);
> > +
> > +			if (events >= wakeup_events) {
> > +				local_sub(wakeup_events, &rb->events);
> > +				local_inc(&rb->wakeup);
> > +			}
> > +		}
> > +	}
> > +
> >  	if (unlikely(head - local_read(&rb->wakeup) > rb->watermark))
> >  		local_add(rb->watermark, &rb->wakeup);
> >  
> 
> So this is a very performance sensitive function; not at all happy to
> add bits here ... :/

:O

Does it at all help if the above is instead guarded by:
	if (unlikely(event->attr.count_sb_events)) {
		...
	}

That should hopefully limit the impact to only when that option is used?


Thanks,
Naveen