I briefly discussed this with Barrett last week, but having userspace apps
configuring counters (both for simple reading, and for trace sampling -
overflow IRQs based sampling), is not going to work.
First, because counters are a very limited resource, and there needs to be
an allocation/free model on such limited resource.
Second, because many counters operation requires a read-modify-write cycle,
which becomes racy if more than one process is doing it at the same time.
So, the idea (more than idea, because Akaros perf is actually already done
using that model) of simple MSR read/write from userspace, is not going to
be a reliable design.
There needs to be a small module in the kernel, which exposes both counter
allocations, and their atomic configuration access.
The idea is that you open a kernel device/file, which instantiate a
counters management session.
Within such session, counter allocation lives, and are teared down when the
device/file is closed.
Also, manipulating session's counters, will happen through the dedicated
device, and not by read-modify-write cycles in userspace.
So, the perf usage to read a set of counters will be something like:
$ perf -e C0 -e C1 -e C2 -- sleep 10
What this does is, open the PMC device and hence a new counters session,
allocate 3 counters, set them up, run the command specified after --, wait
for its termination, read the counters values, close the device (which
frees the three counters).
Above, I mentioned a PMC device, but that's not the only option.
Another option is a set (at least three - open, close, control - where the
latter is a multiplexed API with many commands) of PMC system calls, that
allow userspace to interact with the kernel PMC module.
A PMC device will forcibly need an ioctl() like entry though.
I am not sure how an ioctl() (or even things like passing pointers are
pread/pwrite offsets) is going to work with the plan9 remote device/file
access.
If plan9 generates string commands to the remote site, when accessing such
remote site device, passing pointers for things that are offsets, are going
to be pretty interesting on the remote site, where we will be pointing to
unrelated memory 😀
This is similar for ioctl() like things.
Take this for example:
struct my_ioctl_1 {
int op;
long flags;
int count;
const void *source;
};
How is the local side, going to marshal such a thing on the remote site,
where the actual device lives?
In there, there is a pointer to local site userspace memory, which would
make no sense for the remote site.
In order for that to work, either the marshaling APIs need to know about
every single data structure (unthinkable), or pointers needs to be
expressed in terms of offsets from the beginning of the block, so that the
marshaling code simply transfers a big block on the other side:
[bigblock]
struct my_ioctl_1 {
uint32_t op;
uint64_t flags;
uint32_t count;
uint64_t source_offset;
} cmd;
char data[count]
[/bigblock]
When the device-side will have to write to a pointer specified in an
ioctl() data structure, things can get even more interesting.
Also, I am not even sure in this PMC case, what it means to export a PMC
device to another machine where the binary runs.
All in all, I think for the PMC case, system calls are the better option.
"Or do I owe her an apology?" 😀
--
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.
