linux-kernel - Re: [PATCH v4 00/16] perf, persistent: Add persistent events

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: <20140509085252.GS32718@rric.localhost>
Date:	Fri, 9 May 2014 10:52:52 +0200
From:	Robert Richter <rric@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Jean Pihet <jean.pihet@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
	Tomasz Nowicki <tomasz.nowicki@...aro.org>
Subject: Re: [PATCH v4 00/16] perf, persistent: Add persistent events

On 08.05.14 20:36:29, Borislav Petkov wrote:
> On Wed, May 07, 2014 at 07:01:55PM +0200, Robert Richter wrote:
> > For general-purpose... Why 512k buffers are ok? Depending on the
> > event, smaller buffers are maybe good enough, esp. since they are
> > permanently enabled and use system resources. Or, at some point, 512k
> > is not sufficient anymore. You don't want 512k be carved in stone.
> 
> Well, if it turns out that 512K is not enough, it will be changed in
> perf itself, right?

This requires patching the kernel.

> 
> And we still don't care because no matter the size, the persistent
> buffers overwrite themselves on fill up. If they'd stopped, they're not
> really persistent, right?

If the buffer size does not fit it might either use too much resources
in the system or overwrite its own samples before reading it.

Fixed buffers might work and are good enough in the beginning. If all
users can live with it, fine. But if not, the design does not allow
changes in API without breaking it. What's that I care about and
what's we should think about while designing the i/f.

-Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/