About perf

[Davide Libenzi]

I wanted to get an idea of the objective of this effort.

Is it "giving Akaros a better tool for performance monitoring", or is it "writing something from scratch proprietary to Akaros"?

I took a bit deeper look at Linux one, and though it is A LOT of code, IMHO the former could take less time to achieve (sparing some time for other OKRs).

This is still based on a preliminary analysis though, but I nevertheless wanted to get a feeling about the preferred option.

Another thing, of which perf make use, and which IMO makes sense to be adding along the way, is RCU.

Linux network stack makes use of that as well.

This does not need to be implemented like the Linux one, especially in relation to where and when to run the RCU kthreads.

What is your thought about that?

[Dan Cross]

On Sun, Oct 18, 2015 at 10:44 AM, 'Davide Libenzi' via Akaros <aka...@googlegroups.com> wrote:

I wanted to get an idea of the objective of this effort.

Is it "giving Akaros a better tool for performance monitoring", or is it "writing something from scratch proprietary to Akaros"?

It is the former, but with the caveat that whatever we add should follow the Akaros model.

I took a bit deeper look at Linux one, and though it is A LOT of code, IMHO the former could take less time to achieve (sparing some time for other OKRs).

How much code are we talking about? One of the fears about bringing in Linux code is that it seems to all be pretty tightly intertwined; that is, it seems hard to bring in *just* the perf code in isolation since that drags in a lot of other infrastructure. On the other hand, if it's just large but otherwise self-contained, that's fine.

This is still based on a preliminary analysis though, but I nevertheless wanted to get a feeling about the preferred option.

Another thing, of which perf make use, and which IMO makes sense to be adding along the way, is RCU.

Hmm. I'm not so sure RCU is the way to go. MVCC is cool, but scalable locks seem simpler and easier to understand.

https://people.csail.mit.edu/nickolai/papers/boyd-wickizer-locks.pdf

Linux network stack makes use of that as well.

This does not need to be implemented like the Linux one, especially in relation to where and when to run the RCU kthreads.

What is your thought about that?

In general: I don't think we have an aversion to taking things from Linux (or anywhere else we are permitted to take from, for that matter). But I don't think we want to take them from any one place *just* because they're better than what we have. Rather, we should survey the field and take the *best* solution, where *best* is a combination of performance, functionality and matching our model of the world (in increasing order of importance). That may mean that we invent something new, lift an interface but not the implementation, etc.

[Davide Libenzi]

On Sun, Oct 18, 2015 at 12:06 PM, Dan Cross <cro...@gmail.com> wrote:

How much code are we talking about? One of the fears about bringing in Linux code is that it seems to all be pretty tightly intertwined; that is, it seems hard to bring in *just* the perf code in isolation since that drags in a lot of other infrastructure. On the other hand, if it's just large but otherwise self-contained, that's fine.

It's quite a bit of code, between userspace tool and kernel code.

Kernel, should be around 30K..35K, while userspace perf tool is about 70K.

But, we could avoid that, if we process .dat files out of Akaros.

It has cool stuff, like perf-top, which we'd lose, but maybe we can live with that.

It kinda like ncurses though. Do we have a working ncurses for Akaros?

 

This is still based on a preliminary analysis though, but I nevertheless wanted to get a feeling about the preferred option.

Another thing, of which perf make use, and which IMO makes sense to be adding along the way, is RCU.

Hmm. I'm not so sure RCU is the way to go. MVCC is cool, but scalable locks seem simpler and easier to understand.

https://people.csail.mit.edu/nickolai/papers/boyd-wickizer-locks.pdf

It's hard to beat a lock, which does not take a lock at all on the reader side, like RCU.

There is no shared cacheline where you do atomic operations to add yourself to queues or bump counters.

In Linux all RCU read lock does, is disable preemption. Which is setting a bit in the task thread struct.

In Akaros, since does not have kernel preemption, we would not even need that.

That said, RCU is not the cure for everything.

In many cases you need a spinlock, and there there are many theories of what is the best implementation.

Being this computer science, where given a problem there are at least 100 solutions, 50 of which works reasonably well, the spinlock topic can suggest different implementation depending on the load you are measuring performance with.

I see kernel side, for perf, use heavily percpu queues (EZPZ - we already have), and RCU.

[Davide Libenzi]

Above, when I say 'K', it's kilo-lines-of-code, not KB ☺

[ron minnich]

It's a distributed system. import the name space from the akaros side, run the commands on linux. Done. 

I used to run the equivalent of top for one node on a different node all the time. 

We don't need to port all the viewers to akaros I think. 

But, this is pretty exciting if perf seems achieveable :-)

ron

--
You received this message because you are subscribed to the Google Groups "Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akaros+un...@googlegroups.com.
To post to this group, send email to aka...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.