[lkml]   [2005]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Perfctr-devel] Re: Enabling RDPMC in user space by default
    On Tuesday 29 November 2005 17:39, Andi Kleen wrote:
    > > Well, if that's all you want them to use RDPMC 0 for, why not just make
    > > PMCs programmable from userspace?
    > First we need to have a cycle counter PMC anyways for the NMI watchdog.
    > So it can as well be used for other purposes.

    Yes, but that assumes having the NMI watchdog around is more important to you
    than having 4 performance counters available. I'm perfectly willing to
    have the NMI watchdog around by default, since it seems to be useful in most
    cases. But if my measurement study needs 4 PMC's to do its job and I am
    willing to forgo use of the NMI watchdog for that period of time, why
    shouldn't I be allowed to do that? We have few enough PMCs anyway, I just
    don't like the idea of giving one up forever. I'd much prefer to make that
    decision myself rather than have it enforced by the OS. Let me make the
    tradeoffs about which is the most valuable in my particular situation,

    Furthermore, if I know what I am doing, I can still make use of the RDTSC to
    do timing. Yes, I have to pin the process to the current cpu and yes I have
    to force the power state to a known setup, and oh yeah, we have to turn off
    the halt in the idle loop, etc., etc., but after doing it works quite nicely,
    thank you. And you've got a tremendous education problem to get people not
    to use the RDTSC and lots of existing programs that have to be modified.

    So, sure, allow RDPMC from ring 3. For people who want to use RDPMC and
    performance counter 0 for timing, let them do that.

    The real issue here is that there needs to be a defined kernel interface to
    allow user programs to allocate and use PMCs and that is part of what this
    whole discussion on the perfctr-devel mailing list has been about. Let's
    get that defined and then if a user requests PMC0 and insists on using it,
    then perhaps the NMI watchdog will simply have to go away until PMC0 is
    available to the kernel again.

    I'm also not sure what the performance tradeoff between RDTSC/P and RDPMC is
    across processor implementations, now and future. That's something that
    needs to be looked at.

    > And using virtual performance counters adds a large cost the
    > context switch for changing the MSRs around. An always running counter
    > avoids this problem.
    > -Andi

    Ray Bryant
    AMD Performance Labs Austin, Tx
    512-602-0038 (o) 512-507-7807 (c)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-11-30 01:11    [W:0.026 / U:26.188 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site