[lkml]   [2009]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [bisected] pty performance problem

    * Alan Cox <> wrote:

    > > > So you'd prefer to detect devices that are byte based or message based
    > > > by what method ?
    > >
    > > I'd not delay the worklet by default - i.e. i'd do Mike's patch.
    > Certainly stuff like pty should not delay
    > >
    > > Havent tested all effects of it though - do you have any estimation
    > > about negative effects from such a change? We do have hard numbers
    > > (latencies in the millisecs range) from the opposite direction and those
    > > numbers arent pretty.
    > On a PC I'm not too worried - we might burn a bit more CPU and Arjan
    > might even manage to measure it somewhere. There is the theoretical bad
    > case where we end up at 100% CPU because the irq, wake, process one char,
    > irq wake, process one char sequence fits the CPU so we don't sleep.
    > Embedded might be more of a concern, the old behaviour comes from 386/486
    > days with low CPU power.
    > USB doesn't worry me - USB devices generally have their own buffering
    > algorithm and use a timer so that they batch data efficiently into USB
    > buffers.
    > The drivers/serial layer is often run with low latency set anyway so that
    > seems to be ok for the most part.
    > Give it a go, send the patch to the maintainer, try it in -next and see
    > if anyone screams.

    (Doh, i should have Cc:-ed Greg first time around - fixed that.)


     \ /
      Last update: 2009-11-23 18:51    [W:0.022 / U:14.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site