There is no reason, for the perf case, to have a single user, as long as they go through a kernel API to manipulate (and allocate) the MSRs. You can have one user wanting to watch TLB flushes, and another branch misses, for example. Where it gets overlapped, is when one wants to trace by time sampling, and one by counter overflow sampling. I am planning to add an ID to the trace sample, but I need to re-look at Linux perf format and how to pass it to it.
On Sat, Nov 28, 2015 at 7:27 AM, ron minnich <[email protected]> wrote: > On Plan 9 the model is that ctl files are text, since it's a distributed > system; data files are arbitrary. I was just looking at the draw device and > it's an interesting example of a data file with structure such that you can > import the draw device from (e.g.) an ARM to (e.g.) an x86, which is what > we do when we use the 'cpu' command. > > http://man.cat-v.org/plan_9/3/draw > > I have no idea if this helps but there it is. > > I kind of agree with Davide that a clone file is not needed. You can > differentiate sessions in the chan you get from open. > > Also, depending on usage, one thing that we might pick up from Plan 9 is > the 'single open' attribute, which if set on a file is honored by the > kernel: the file can only be open by one user at a time. This works because > servers honor it too. It's handy. > > Hope this helps ... > > ron > > On Sat, Nov 28, 2015 at 7:22 AM 'Davide Libenzi' via Akaros < > [email protected]> wrote: > >> Also, any reason why those could not be static inline (and turned into >> something like get_u16, put_u16, ...)? >> Are they something coming from imported code, which we do not want to >> change name? >> >> >> On Sat, Nov 28, 2015 at 7:19 AM, Davide Libenzi <[email protected]> >> wrote: >> >>> On Fri, Nov 27, 2015 at 9:16 AM, barret rhoden <[email protected]> >>> wrote: >>> >>>> > Question. Should I force the payloads to be strings, or should I use >>>> > binary? Example: >>>> > >>>> > struct req1 { >>>> > uint32_t size; >>>> > uint32_t req; >>>> > uint32_t cnt; >>>> > uint64_t something[NMAX]; >>>> > }; >>>> >>>> You could also use a binary, arch-independent format. That struct has >>>> endianness assumptions. But you can still use a binary format of your >>>> choosing. >>>> >>>> For another example, in Plan 9 (and Akaros), when we read() a >>>> directory, we get a byte stream of format 'M'. In Akaros, we convert >>>> those to structs for our own processing (e.g. convM2kdirent(), which >>>> you can see in a few places in kern/src/ns/sysfile.c). There are >>>> similar ones, e.g. convM2D(). >>>> >>>> There's a bunch of helpers to convert from bytes to fields, e.g. >>>> GBIT8() and write fields as bytes (PBIT8()). >>>> >>>> What I'd do is come up with what you want the structs to look like, >>>> then write little conv() helpers. For example: >>>> >>>> conv_req1_to_X(struct req1 *req1, uint8_t *buf, size_t len) >>>> { >>>> PBIT32(buf, req1->size); >>>> buf += BIT32SZ; >>>> PBIT32(buf, req1->req); >>>> buf += BIT32SZ; >>>> PBIT32(buf, req1->cnt); >>>> buf += BIT32SZ; >>>> for (int i = 0; i < NMAX; i++) { >>>> PBIT64(buf, req1->something); >>>> buf += BIT64SZ; >>>> } >>>> } >>>> >>>> (written hastily, checkout convD2M for a better example). >>>> >>> >>> These interfaces though, are not exposed to userspace, so I will have to >>> move them into a dedicated ros/ file, I guess? >>> >>> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
