On 26.08.2018 02:40, Kamil Rytarowski wrote:
> On 25.08.2018 21:32, David Holland wrote:
>> > 2. There is no bpf_validate for Lua bytecode. In fact, Lua team abandoned
>> >an idea of bytecode validation few years ago. From Lua 5.3 manual:
>> >
>> >Lua does not check the consistency of
On 25.08.2018 21:32, David Holland wrote:
> > 2. There is no bpf_validate for Lua bytecode. In fact, Lua team abandoned
> >an idea of bytecode validation few years ago. From Lua 5.3 manual:
> >
> >Lua does not check the consistency of binary chunks. Maliciously
> >crafted binary
David Holland wrote:
> On Sat, Aug 25, 2018 at 11:26:07AM +0100, Alexander Nasonov wrote:
> > 1. It's not standartised and it will very likely change in future versions
>
> That doesn't really matter as long as you're only using one version at
> a time...
If bytecode is generated from a valid
On Fri, Aug 10, 2018 at 11:40:20AM +0200, Maxime Villard wrote:
> 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.
>
> I agree that it would be better to retire gprof
On Sat, Aug 25, 2018 at 11:26:07AM +0100, Alexander Nasonov wrote:
> > There is already a Lua-powered solution for traces in Linux: ktap. It
> > uses nice rules written natively in Lua.. however it seems to be
> > abandoned in favor of eBPF.
>
> I see two potential problems with using Lua
Kamil Rytarowski wrote:
> There is already a Lua-powered solution for traces in Linux: ktap. It
> uses nice rules written natively in Lua.. however it seems to be
> abandoned in favor of eBPF.
I see two potential problems with using Lua bytecode:
1. It's not standartised and it will very likely
On 25.08.2018 00:28, Rhialto wrote:
> On Thu 23 Aug 2018 at 18:48:32 +0200, Kamil Rytarowski wrote:
>> Probably DTrace is not the final word in BSD and not something I intend
>> to defend - but it's a good solution for now - (FreeBSD already
>> ports/develops a potential replacement eBPF).
>
> I
On Thu 23 Aug 2018 at 18:48:32 +0200, Kamil Rytarowski wrote:
> Probably DTrace is not the final word in BSD and not something I intend
> to defend - but it's a good solution for now - (FreeBSD already
> ports/develops a potential replacement eBPF).
I have played a bit with EBPF on Linux, and it
On Aug 23, 11:57am, t...@panix.com (Thor Lancelot Simon) wrote:
-- Subject: Re: Too many PMC implementations
| On Thu, Aug 23, 2018 at 05:09:35PM +0200, Kamil Rytarowski wrote:
| >
| > Observing that all the useful profiling is already done with DTrace, we
| > can remove comple
On Thu, Aug 23, 2018 at 10:17:29AM -0700, Jason Thorpe wrote:
>
> > On Aug 23, 2018, at 8:47 AM, Anders Magnusson wrote:
>
> > I have used it not long ago for vax. Maybe I did have to do some tweaks,
> > do not remember,
> > but I really want to be able to use kernel profiling on vax.
> >
>
> On Aug 23, 2018, at 8:47 AM, Anders Magnusson wrote:
> I have used it not long ago for vax. Maybe I did have to do some tweaks, do
> not remember,
> but I really want to be able to use kernel profiling on vax.
>
> So, I really oppose removing it and leaving vax without any kernel
On 23.08.2018 18:35, Thor Lancelot Simon wrote:
> On Thu, Aug 23, 2018 at 06:25:56PM +0200, Kamil Rytarowski wrote:
>>
>> As useful I mean the number of commits to the src/ tree. If nothing
>> landed, probably nothing was useful. When were the most recent patches
>> from gprof or similar?
>
>
On Thu, Aug 23, 2018 at 06:25:56PM +0200, Kamil Rytarowski wrote:
>
> As useful I mean the number of commits to the src/ tree. If nothing
> landed, probably nothing was useful. When were the most recent patches
> from gprof or similar?
This is a plainly bogus criterion. After we integrated
On 23.08.2018 17:57, Thor Lancelot Simon wrote:
> On Thu, Aug 23, 2018 at 05:09:35PM +0200, Kamil Rytarowski wrote:
>>
>> Observing that all the useful profiling is already done with DTrace, we
>> can remove complexity from the kernel with negligible cost.
>
> I'm not sure what to make of this.
On Thu, Aug 23, 2018 at 05:09:35PM +0200, Kamil Rytarowski wrote:
>
> Observing that all the useful profiling is already done with DTrace, we
> can remove complexity from the kernel with negligible cost.
I'm not sure what to make of this. I'm trying to come up with a way to
make the above
Den 2018-08-23 kl. 17:09, skrev Kamil Rytarowski:
On 23.08.2018 16:59, Anders Magnusson wrote:
Den 2018-08-23 kl. 16:48, skrev Kamil Rytarowski:
On 23.08.2018 16:28, Anders Magnusson wrote:
Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
On
Den 2018-08-23 kl. 17:03, skrev Maxime Villard:
Le 23/08/2018 à 16:28, Anders Magnusson a écrit :
Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
On 17.08.2018 17:13, Maxime Villard wrote:
Note that I'm talking about the kernel gprof, and not
On 23.08.2018 16:59, Anders Magnusson wrote:
> Den 2018-08-23 kl. 16:48, skrev Kamil Rytarowski:
>> On 23.08.2018 16:28, Anders Magnusson wrote:
>>> Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
> On 17.08.2018 17:13, Maxime Villard
Le 23/08/2018 à 16:28, Anders Magnusson a écrit :
Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
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
Den 2018-08-23 kl. 16:48, skrev Kamil Rytarowski:
On 23.08.2018 16:28, Anders Magnusson wrote:
Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
On 17.08.2018 17:13, Maxime Villard wrote:
Note that I'm talking about the kernel gprof, and not
On 23.08.2018 16:28, Anders Magnusson wrote:
> Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
>> Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
>>> 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
Den 2018-08-23 kl. 15:53, skrev Maxime Villard:
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
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
Le 17/08/2018 à 17:42, Kamil Rytarowski a écrit :
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
> 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.
>
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.
I agree that it would be better to retire gprof in base, because there are
more powerful tools now, and also advanced
On Sun, 15 Jul 2018, Maxime Villard wrote:
Now I want to move:
arch/x86/x86/tprof_pmi.c
arch/x86/x86/tprof_amdpmi.c
into
dev/tprof/tprof_intel.c
dev/tprof/tprof_amd.c
I guess people are fine? I think it is better to gather all the pieces in
one dir.
I don't
Le 11/07/2018 à 18:22, Maxime Villard a écrit :
Right now we have three (or more?) different implementations for Performance
Monitoring Counters:
* PMC: this one is MI. It is used only on one ARM model (xscale I think).
There used to be an x86 code for it, but it was broken, and I removed
On 12.07.2018 08:48, Maxime Villard wrote:
> Le 11/07/2018 à 19:49, Kamil Rytarowski a écrit :
>> I'm not familiar with the internals myself, but from API point of view,
>> something usable for porting rr (https://github.com/mozilla/rr) or even
>> Linux perf-top is highly desirable. I treat
Le 11/07/2018 à 18:22, Maxime Villard a écrit :
Right now we have three (or more?) different implementations for Performance
Monitoring Counters:
* PMC: this one is MI. It is used only on one ARM model (xscale I think).
There used to be an x86 code for it, but it was broken, and I removed
Le 11/07/2018 à 19:49, Kamil Rytarowski a écrit :
I'm not familiar with the internals myself, but from API point of view,
something usable for porting rr (https://github.com/mozilla/rr) or even
Linux perf-top is highly desirable. I treat personally perf-top as a
gold standard.
Well, yes, but
On 11.07.2018 18:22, Maxime Villard wrote:
> Right now we have three (or more?) different implementations for
> Performance
> Monitoring Counters:
>
> * PMC: this one is MI. It is used only on one ARM model (xscale I think).
> There used to be an x86 code for it, but it was broken, and I
Speaking as someone who was peripherally involved in the PMC flavor below, I
have no objections to this.
> On Jul 11, 2018, at 9:22 AM, Maxime Villard wrote:
>
> Right now we have three (or more?) different implementations for Performance
> Monitoring Counters:
>
> * PMC: this one is MI. It
Right now we have three (or more?) different implementations for Performance
Monitoring Counters:
* PMC: this one is MI. It is used only on one ARM model (xscale I think).
There used to be an x86 code for it, but it was broken, and I removed it.
The implementation comes with libpmc, a
37 matches
Mail list logo
