[lkml]   [2000]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: a joint letter on low latency and Linux
    Martin Mares said this...
    >> Note that printk() during normal kernel operations _is_ a bug.
    >> printk() should happen only for (a) initialization and (b) exceptional
    >> events. I fyou get printk's while doing streaming audio, you have other
    >> trouble, and whatever causes that trouble should be fixed.
    > Agreed. But if we want to allow printk's in those emergency situations, we
    >still must lock the console subsystem somehow to avoid collisions between
    >normal console output and the printk's. The most ugly point is that some
    >gfx cards (Matrox, to name one) lock up when trying to touch the frame buffer
    >while the accelerator accesses it. And these locks definitely should not
    >keep interrupts disabled as they do now. Being a sssslllooowww action,
    >scrolling of the FB should be interruptible and perhaps even preemptive.

    I'm not sure why printk() needs to have a complicated algorithm. Under
    normal circumstances (that were pointed out above) (a) happens on boot and
    there shouldn't be much problem with locks, and (b) only happens when
    there's a problem so even if it is slow in this case, it's only reporting
    that something went wrong (or some debugging messages that would be
    removed before the code is 'published'.)

    I admit that I'm very much a newbie here, but it seems that the effort to
    make a faster printk() would be better off in other areas, since, in the
    best of all worlds, it wouldn't ever be used during normal operation


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

     \ /
      Last update: 2005-03-22 13:57    [W:0.027 / U:1.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site