Re: debugctl msr

["stephane eranian" <eranian@googlemail.com>]

Markus,

On Wed, Nov 12, 2008 at 8:09 AM, Markus Metzger
<markus.t.metzger@googlemail.com> wrote:
> stephane eranian wrote:
>
>> For perfmon, PEBS can be used for both per-thread and per-cpu. With
>> perfmon, the allocation/initialization of the buffer is separated from its
>> activation. In other words, allocation/initialization may be done before
>> you
>> actually have to write the DS_AREA MSR. Allocation/initialization may not
>> necessary be done on the cpu you want to measure in per-cpu mode. The
>> logic of DS is different, ds_request_pebs() allocates and immediately
>> writes
>> DS_AREA. I cannot use that.
>
> DS_AREA contains a pointer to the actual configuration struct.
> The idea is that once I allocated the configuration struct, I can write
> the pointer to it into DS_AREA. It won't be used unless I turn on a feature
> that uses DS.
> So, the flow is:
> 1. allocate configuration struct
> 2. write DS_AREA

What if you are allocating the buffer for another task. For instance,
a tool is attaching
to a running process and wants to use PEBS. The tool allocates and
initializes the
PEBS buffer and then attaches it to the task to monitor (which is
stopped). When the
task is scheduled again, it picks up the PEBS buffer, and DS_AREA is written to.

> 3. configure BTS/PEBS
> 4. enable BTS/PEBS

enable PEBS consists in writing a PMU MSR. Perfmon takes care of that.

>
>
>> Concerning memory allocation of the buffer, the current kernel module
>> exporting PEBS lumps together the memory for the DS_AREA + PEBS
>> buffer. The entire region is then remapped to user space via mmap().
>> That implies that the memory region needs to be page-aligned and multiple
>> of page size. If I wanted to keep this, it is not clear to me how I could
>> use
>> your API to simply pass the addresses.
>
> Higher layers are not meant to know about DS configuration details. I admit
> that
> the interface is still very near to the actual h/w and that the developers
> of
> higher layers do of course know DS details. But they should not care, for
> example, that DS configuration requires memory allocation.
>
> The DS configuration is shared between PEBS and BTS users.
> Assuming there is already a BTS user for that thread or cpu. What should
> ds.c
> do with the memory you allocated for the DS configuration? It must have
> already
> allocated one to satisfy the BTS user.
>
> Besides, I would not expose this configuration to user-space. If the user
> were
> to modify the configuration, he could bring down the system. The PEBS/BTS
> buffers should be save, since they are write-only from h/w perspective.
>
The PEBS buffer (and thus DS_AREA) are remapped read-only.

There is another reason why the DS_AREA is exposed. This is the only way for
tools to see the current position in the PEBS buffer. They may want to poll on
that position index. The PEBS buffer is not necessarily full. What if
the session
terminates with a partial buffer. There must be a way for the tool to figure out
where the last sample is. By exposing DS read-only the index is always available
and always guaranteed current. Without this, the kernel would have to
extract the
index (pebs_get_index) and store it somewhere so the user can see it. This copy
could be tirggered by a PEBS buffer overflow or a stop of monitoring. Sampling
buffers formats currently do not have a stop callback but this can be
added easily.