> On Aug 17, 2018, at 8:42 AM, Kamil Rytarowski wrote:
>
> Speaking realistically, probably all the recent software-based kernel
> profiling was done with DTrace.
Yah, I suppose I'm okay will killing off kernel GPROF support ... you can
essentially do the same-thing-but-better with an
On 17.08.2018 17:13, Maxime Villard wrote:
> Note that I'm talking about the kernel gprof, and not the userland gprof.
> In terms of kernel profiling, it's not nonsensical to say that since we
> support ARM and x86 in tprof, we can cover 99% of the MI parts of
> whatever architecture. From then
Le 17/08/2018 à 16:43, Joerg Sonnenberger a écrit :
On Fri, Aug 17, 2018 at 04:20:30PM +0200, Maxime Villard wrote:
So no one has any opinion on that? Because in this case I will remove it
soon. (Talking about the kernel gprof.)
I'm quite reluctant to remove the only sample based profiler we
>> I agree that it would be better to retire gprof in base, because
>> there are more powerful tools now, and also advanced hardware
>> support (PMC, PEBS, ProcessorTrace).
...for ports that _have_ "advanced hardware support", maybe. (And what
are the "more powerful tools"? I haven't been
On Fri, Aug 17, 2018 at 04:20:30PM +0200, Maxime Villard wrote:
> Le 10/08/2018 à 11:40, Maxime Villard a écrit :
> > I saw the thread [Re: Sample based profiling] on tech-userlevel@, I'm not
> > subscribed to this list but I'm answering here because it's related to
> > tprof among other things.
>
> Le 17 août 2018 à 07:07, Michael van Elst a écrit :
>
>> On Fri, Aug 17, 2018 at 02:23:16AM +, Emmanuel Dreyfus wrote:
>>
>>blkif_response_t *rep = RING_GET_RESPONSE(>sc_ring, i);
>>struct xbd_req *xbdreq = >sc_reqs[rep->id];
>>bp =
> On 17. Aug 2018, at 04:46, Emmanuel Dreyfus wrote:
>
> On Thu, Aug 16, 2018 at 10:03:11AM +0200, J. Hannken-Illjes wrote:
>> Looks like a deadlock where we sync a file system, need a new buffer
>> and try to free a buffer on a currently suspending file system.
>>
>> VFS_SYNC and VOP_BWRITE
