On Tue, Sep 11, 2018 at 04:42:09PM +0300, Alexey Budankov wrote:
> Hi,
>
> On 11.09.2018 11:34, Jiri Olsa wrote:
> > On Tue, Sep 11, 2018 at 11:16:45AM +0300, Alexey Budankov wrote:
> >>
> >> Hi Ingo,
> >>
> >> On 11.09.2018 9:35, Ingo Molnar wrote:
> >>>
> >>> * Alexey Budankov wrote:
> >>>
>
On Tue, Sep 11, 2018 at 04:42:09PM +0300, Alexey Budankov wrote:
> Hi,
>
> On 11.09.2018 11:34, Jiri Olsa wrote:
> > On Tue, Sep 11, 2018 at 11:16:45AM +0300, Alexey Budankov wrote:
> >>
> >> Hi Ingo,
> >>
> >> On 11.09.2018 9:35, Ingo Molnar wrote:
> >>>
> >>> * Alexey Budankov wrote:
> >>>
>
Hi,
On 11.09.2018 17:19, Peter Zijlstra wrote:
> On Tue, Sep 11, 2018 at 08:35:12AM +0200, Ingo Molnar wrote:
>>> Well, explicit threading in the tool for AIO, in the simplest case, means
>>> incorporating some POSIX API implementation into the tool, avoiding
>>> code reuse in the first
Hi,
On 11.09.2018 17:19, Peter Zijlstra wrote:
> On Tue, Sep 11, 2018 at 08:35:12AM +0200, Ingo Molnar wrote:
>>> Well, explicit threading in the tool for AIO, in the simplest case, means
>>> incorporating some POSIX API implementation into the tool, avoiding
>>> code reuse in the first
On Tue, Sep 11, 2018 at 08:35:12AM +0200, Ingo Molnar wrote:
> > Well, explicit threading in the tool for AIO, in the simplest case, means
> > incorporating some POSIX API implementation into the tool, avoiding
> > code reuse in the first place. That tends to be error prone and costly.
>
> It's
On Tue, Sep 11, 2018 at 08:35:12AM +0200, Ingo Molnar wrote:
> > Well, explicit threading in the tool for AIO, in the simplest case, means
> > incorporating some POSIX API implementation into the tool, avoiding
> > code reuse in the first place. That tends to be error prone and costly.
>
> It's
Hi,
On 11.09.2018 11:34, Jiri Olsa wrote:
> On Tue, Sep 11, 2018 at 11:16:45AM +0300, Alexey Budankov wrote:
>>
>> Hi Ingo,
>>
>> On 11.09.2018 9:35, Ingo Molnar wrote:
>>>
>>> * Alexey Budankov wrote:
>>>
It may sound too optimistic but glibc API is expected to be backward
compatible
Hi,
On 11.09.2018 11:34, Jiri Olsa wrote:
> On Tue, Sep 11, 2018 at 11:16:45AM +0300, Alexey Budankov wrote:
>>
>> Hi Ingo,
>>
>> On 11.09.2018 9:35, Ingo Molnar wrote:
>>>
>>> * Alexey Budankov wrote:
>>>
It may sound too optimistic but glibc API is expected to be backward
compatible
On Tue, Sep 11, 2018 at 11:16:45AM +0300, Alexey Budankov wrote:
>
> Hi Ingo,
>
> On 11.09.2018 9:35, Ingo Molnar wrote:
> >
> > * Alexey Budankov wrote:
> >
> >> It may sound too optimistic but glibc API is expected to be backward
> >> compatible
> >> and for POSIX AIO API part too.
On Tue, Sep 11, 2018 at 11:16:45AM +0300, Alexey Budankov wrote:
>
> Hi Ingo,
>
> On 11.09.2018 9:35, Ingo Molnar wrote:
> >
> > * Alexey Budankov wrote:
> >
> >> It may sound too optimistic but glibc API is expected to be backward
> >> compatible
> >> and for POSIX AIO API part too.
Hi Ingo,
On 11.09.2018 9:35, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
>> It may sound too optimistic but glibc API is expected to be backward
>> compatible
>> and for POSIX AIO API part too. Internal implementation also tends to evolve
>> to
>> better option overtime, more
Hi Ingo,
On 11.09.2018 9:35, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
>> It may sound too optimistic but glibc API is expected to be backward
>> compatible
>> and for POSIX AIO API part too. Internal implementation also tends to evolve
>> to
>> better option overtime, more
* Alexey Budankov wrote:
> It may sound too optimistic but glibc API is expected to be backward
> compatible
> and for POSIX AIO API part too. Internal implementation also tends to evolve
> to
> better option overtime, more probably basing on modern kernel capabilities
> mentioned here:
* Alexey Budankov wrote:
> It may sound too optimistic but glibc API is expected to be backward
> compatible
> and for POSIX AIO API part too. Internal implementation also tends to evolve
> to
> better option overtime, more probably basing on modern kernel capabilities
> mentioned here:
Hi,
On 10.09.2018 16:58, Arnaldo Carvalho de Melo wrote:
> Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
>> * Alexey Budankov wrote:
>>> On 10.09.2018 12:18, Ingo Molnar wrote:
* Alexey Budankov wrote:
> Currently in record mode the tool implements trace writing
Hi,
On 10.09.2018 16:58, Arnaldo Carvalho de Melo wrote:
> Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
>> * Alexey Budankov wrote:
>>> On 10.09.2018 12:18, Ingo Molnar wrote:
* Alexey Budankov wrote:
> Currently in record mode the tool implements trace writing
Hi Ingo,
On 10.09.2018 15:06, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
>> Hi Ingo,
>>
>> On 10.09.2018 12:18, Ingo Molnar wrote:
>>>
>>> * Alexey Budankov wrote:
>>>
Currently in record mode the tool implements trace writing serially.
The algorithm loops over mapped
Hi Ingo,
On 10.09.2018 15:06, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
>> Hi Ingo,
>>
>> On 10.09.2018 12:18, Ingo Molnar wrote:
>>>
>>> * Alexey Budankov wrote:
>>>
Currently in record mode the tool implements trace writing serially.
The algorithm loops over mapped
Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
> * Alexey Budankov wrote:
> > On 10.09.2018 12:18, Ingo Molnar wrote:
> > > * Alexey Budankov wrote:
> > >> Currently in record mode the tool implements trace writing serially.
> > >> The algorithm loops over mapped per-cpu data
Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
> * Alexey Budankov wrote:
> > On 10.09.2018 12:18, Ingo Molnar wrote:
> > > * Alexey Budankov wrote:
> > >> Currently in record mode the tool implements trace writing serially.
> > >> The algorithm loops over mapped per-cpu data
* Alexey Budankov wrote:
> Hi Ingo,
>
> On 10.09.2018 12:18, Ingo Molnar wrote:
> >
> > * Alexey Budankov wrote:
> >
> >>
> >> Currently in record mode the tool implements trace writing serially.
> >> The algorithm loops over mapped per-cpu data buffers and stores
> >> ready data chunks
* Alexey Budankov wrote:
> Hi Ingo,
>
> On 10.09.2018 12:18, Ingo Molnar wrote:
> >
> > * Alexey Budankov wrote:
> >
> >>
> >> Currently in record mode the tool implements trace writing serially.
> >> The algorithm loops over mapped per-cpu data buffers and stores
> >> ready data chunks
Hi,
On 10.09.2018 13:23, Jiri Olsa wrote:
> On Mon, Sep 10, 2018 at 12:13:25PM +0200, Ingo Molnar wrote:
>>
>> * Jiri Olsa wrote:
>>
>>> On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
* Jiri Olsa wrote:
>> Per-CPU threading the record session would have so many
Hi,
On 10.09.2018 13:23, Jiri Olsa wrote:
> On Mon, Sep 10, 2018 at 12:13:25PM +0200, Ingo Molnar wrote:
>>
>> * Jiri Olsa wrote:
>>
>>> On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
* Jiri Olsa wrote:
>> Per-CPU threading the record session would have so many
Hi Ingo,
On 10.09.2018 12:18, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
>>
>> Currently in record mode the tool implements trace writing serially.
>> The algorithm loops over mapped per-cpu data buffers and stores
>> ready data chunks into a trace file using write() system call.
>>
Hi Ingo,
On 10.09.2018 12:18, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
>>
>> Currently in record mode the tool implements trace writing serially.
>> The algorithm loops over mapped per-cpu data buffers and stores
>> ready data chunks into a trace file using write() system call.
>>
On Mon, Sep 10, 2018 at 12:13:25PM +0200, Ingo Molnar wrote:
>
> * Jiri Olsa wrote:
>
> > On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
> > >
> > > * Jiri Olsa wrote:
> > >
> > > > > Per-CPU threading the record session would have so many other
> > > > > advantages as well
On Mon, Sep 10, 2018 at 12:13:25PM +0200, Ingo Molnar wrote:
>
> * Jiri Olsa wrote:
>
> > On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
> > >
> > > * Jiri Olsa wrote:
> > >
> > > > > Per-CPU threading the record session would have so many other
> > > > > advantages as well
* Jiri Olsa wrote:
> On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
> >
> > * Jiri Olsa wrote:
> >
> > > > Per-CPU threading the record session would have so many other
> > > > advantages as well (scalability,
> > > > etc.).
> > > >
> > > > Jiri did per-CPU recording
* Jiri Olsa wrote:
> On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
> >
> > * Jiri Olsa wrote:
> >
> > > > Per-CPU threading the record session would have so many other
> > > > advantages as well (scalability,
> > > > etc.).
> > > >
> > > > Jiri did per-CPU recording
On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
>
> * Jiri Olsa wrote:
>
> > > Per-CPU threading the record session would have so many other advantages
> > > as well (scalability,
> > > etc.).
> > >
> > > Jiri did per-CPU recording patches a couple of months ago, not sure how
>
On Mon, Sep 10, 2018 at 12:03:03PM +0200, Ingo Molnar wrote:
>
> * Jiri Olsa wrote:
>
> > > Per-CPU threading the record session would have so many other advantages
> > > as well (scalability,
> > > etc.).
> > >
> > > Jiri did per-CPU recording patches a couple of months ago, not sure how
>
* Jiri Olsa wrote:
> > Per-CPU threading the record session would have so many other advantages as
> > well (scalability,
> > etc.).
> >
> > Jiri did per-CPU recording patches a couple of months ago, not sure how
> > usable they are at the
> > moment?
>
> it's still usable, I can rebase
* Jiri Olsa wrote:
> > Per-CPU threading the record session would have so many other advantages as
> > well (scalability,
> > etc.).
> >
> > Jiri did per-CPU recording patches a couple of months ago, not sure how
> > usable they are at the
> > moment?
>
> it's still usable, I can rebase
On Mon, Sep 10, 2018 at 11:18:41AM +0200, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
> >
> > Currently in record mode the tool implements trace writing serially.
> > The algorithm loops over mapped per-cpu data buffers and stores
> > ready data chunks into a trace file using write()
On Mon, Sep 10, 2018 at 11:18:41AM +0200, Ingo Molnar wrote:
>
> * Alexey Budankov wrote:
>
> >
> > Currently in record mode the tool implements trace writing serially.
> > The algorithm loops over mapped per-cpu data buffers and stores
> > ready data chunks into a trace file using write()
* Alexey Budankov wrote:
>
> Currently in record mode the tool implements trace writing serially.
> The algorithm loops over mapped per-cpu data buffers and stores
> ready data chunks into a trace file using write() system call.
>
> At some circumstances the kernel may lack free space in a
* Alexey Budankov wrote:
>
> Currently in record mode the tool implements trace writing serially.
> The algorithm loops over mapped per-cpu data buffers and stores
> ready data chunks into a trace file using write() system call.
>
> At some circumstances the kernel may lack free space in a
On 07.09.2018 10:07, Alexey Budankov wrote:
>
> Currently in record mode the tool implements trace writing serially.
> The algorithm loops over mapped per-cpu data buffers and stores
> ready data chunks into a trace file using write() system call.
>
> At some circumstances the kernel may
On 07.09.2018 10:07, Alexey Budankov wrote:
>
> Currently in record mode the tool implements trace writing serially.
> The algorithm loops over mapped per-cpu data buffers and stores
> ready data chunks into a trace file using write() system call.
>
> At some circumstances the kernel may
40 matches
Mail list logo
