[lkml]   [2011]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible

    * Andi Kleen <> wrote:

    > > Also seriously complicated by the kexec case where the previous kernel
    > > didn't clean up PMU state. There is simply no sane way to detect if its
    > That's a good point, but we can easily stop the PMU before kexec.

    Wrong - there's lots of existing Linux versions out there that will kexec with
    PMU state active. We cannot change them retroactively.

    > > actually used and by whoem.
    > You check if the counter is enabled. If it's already enabled it's used by
    > someone else.

    Wrong - or it can be enabled if it was left enabled accidentally. We treat PMU
    state like we treat other CPU state.

    > > The whole PMU 'sharing' concept championed by Andi is utter crap.
    > Why? It's the same thing as having some less counters.

    Wrong again - 25% or 50% of the events stolen with no user choice is a pretty
    big deal.

    Consider the example in this thread: cachemiss profiling done via perf, which
    needs two events. If one of the generic counters is 'stolen' by a BIOS and
    Linux accepts this silently then it means the loss of real functionality.

    In other words, '25% of a specific hardware functionality stolen by the BIOS'
    (or more) is absolutely not acceptable.

    > [...] You need to already support that for architectural perfmon with
    > variable counters anyways or for sharing with oprofile.

    Wrong, that's different - multiplexing the PMU is obviously done within the OS.
    It's evidently user configurable - users can use oprofile or perf - and the
    user can still fully utilise the PMU to the extent he wishes to - it's his

    It is not possible for the kernel to stop the BIOS from using the PMU though,
    so it's not 'sharing' no matter what 'protocol' is used, it's 'stealing'.

    > > As for simply using it despite the BIOS corrupting it, that might not
    > > always work, the BIOS might simply over-write your state because it
    > > one-sidedly declares to own the MSRs (observed behaviour).
    > Yes, that doesn't work. If someone else is active you have to step back.
    > > Its all a big clusterfuck and really the best way (IMO) is what we have
    > > now to put pressure on and force the BIOS vendors to play nice.
    > It just results in users like Eric being screwed. I doubt that any
    > BIOS writer ever heard about it. Congratulations for a great plan.

    I'd encourage you to think through this topic instead of making derisive
    comments about others ...



     \ /
      Last update: 2011-03-25 20:25    [W:0.024 / U:18.280 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site