Hi, On Wed, Oct 28, 2020 at 1:02 AM Alexey Budankov <alexey.budan...@linux.intel.com> wrote: > > > On 27.10.2020 15:10, Jiri Olsa wrote: > > On Mon, Oct 26, 2020 at 08:59:01PM +0300, Alexey Budankov wrote: > >> > >> On 24.10.2020 18:43, Jiri Olsa wrote: > >>> On Wed, Oct 21, 2020 at 06:52:43PM +0300, Alexey Budankov wrote: > >>>> > >>>> Changes in v2: > >>>> - explicitly added credit tags to patches 6/15 and 15/15, > >>>> additionally to cites [1], [2] > >>>> - updated description of 3/15 to explicitly mention the reason > >>>> to open data directories in read access mode (e.g. for perf report) > >>>> - implemented fix for compilation error of 2/15 > >>>> - explicitly elaborated on found issues to be resolved for > >>>> threaded AUX trace capture > >>>> > >>>> v1: > >>>> https://lore.kernel.org/lkml/810f3a69-0004-9dff-a911-b7ff97220...@linux.intel.com/ > >>>> > >>>> Patch set provides threaded trace streaming for base perf record > >>>> operation. Provided streaming mode (--threads) mitigates profiling > >>>> data losses and resolves scalability issues of serial and asynchronous > >>>> (--aio) trace streaming modes on multicore server systems. The patch > >>>> set is based on the prototype [1], [2] and the most closely relates > >>>> to mode 3) "mode that creates thread for every monitored memory map". > >>> > >>> so what I liked about the previous code was that you could > >>> configure how the threads would be created > >>> > >>> default --threads options created thread for each cpu like > >>> in your change: > >>> > >>> $ perf record -v --threads ... > >>> ... > >>> thread 0 monitor: 0 allowed: 0 > >>> thread 1 monitor: 1 allowed: 1 > >>> thread 2 monitor: 2 allowed: 2 > >>> thread 3 monitor: 3 allowed: 3 > >>> thread 4 monitor: 4 allowed: 4 > >>> thread 5 monitor: 5 allowed: 5 > >>> thread 6 monitor: 6 allowed: 6 > >>> thread 7 monitor: 7 allowed: 7 > >> > >> Yes, it is configurable in the prototype. Even though this patch set > >> doesn't implement that parameters for --thread option, just because > >> VTune doesn't have use cases for that yet, it has still been designed > >> and implemented with that possible extension in mind so it could then > >> be easily added on top of it. > > > > I'm not sure about vtune extensions, but if we are going to > > have --threads option I believe we should make it configurable > > at least to the extend descibed below > > It employs --threads mode only and there are no use cases > observed so far beyond this mode. Do you have or see such > use cases?
I don't know about vtune and other users, but it's an important feature for better performance so I agree with Jiri's opinion to make it flexible for the system requirement. Thanks Namhyung