[lkml]   [2008]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BUG/PATCH] x86 mmiotrace: dynamically disable non-boot CPUs

    * Pekka Paalanen <> wrote:

    > > we should fix this restriction ASAP. Forcibly dropping to UP will
    > > cause mmiotrace to be much less useful for diagnostic purposes of
    > > Linux
    > Ok, how do you propose we solve this?
    > I have asked the question before, and then I had two ideas. Well, the
    > first one was actually your idea (so I hear) to solve the same problem for
    > kmemcheck.
    > - per-cpu page tables
    > - instead of single-stepping, emulate the faulting instruction and never
    > disarm pages during tracing. (Use and modify code from KVM.)
    > I don't believe either of these is easy or fast to implement. Given
    > some months, I might be able to achieve emulation. Page tables are
    > still magic to me.

    yeah - it looks complex. Not a showstopper for now :-)

    but given that Xorg is usually just a single task, do we _really_ need

    > > drivers. We want to enable the mmiotrace-ing of specific devices via
    > > some /sys flag. For example via:
    > >
    > > cat /sys/devices/pci0000\:00/0000\:00\:1f.2/mmiotrace
    > >
    > > this should start mmiotracing of that specific device - or something
    > > like that. Hm?
    > Ooh, that sounds like a neat interface. I like it. I've been
    > half-thinking of different ways of specifying the set of devices to
    > trace, but none of them was particularly nice. This feature is for
    > post-2.6.26, right?

    yeah, most likely.

    > Ok, so first select mmiotrace tracer, at which point those sysfs files
    > appear, but mmiotrace is not activated yet. Then, when any of the
    > device specific files, or the global file in debugfs, is opened,
    > mmiotrace activates. And if the file is closed, mmiotrace deactivates.

    sounds good to me!

    > Should we support several "cats" at the same time?

    if it's possible ...

    > > i suspect the bug is that you bring the CPU down from an atomic
    > > (spinlocked or irq disabled) context.
    > Hmm, it should not be... I have to double-check, but all the other
    > code, too, from where enter_uniprocessor() is called, may sleep. The
    > first thing the caller does is to acquire a mutex, which I assume
    > would complain loudly if spinlocked or irq-disabled.
    > Ingo, thank you for fixing this patch, though I'd like to suggest to
    > leave it out for now, since there clearly are worse problems with it
    > than without it. And if we can solve the SMP issue, this is not
    > needed. For the time being we can just instruct users to disable all
    > but one CPU when try want to trace.

    i think we still need to make this as 'transparent' to users as
    possible. Disabling CPUs can be tedious.

    are lost events really a problem in practice, given Xorg's

    i'm leaving out this patch from the series for now.


     \ /
      Last update: 2008-04-16 13:49    [W:3.874 / U:0.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site