Hello, On Tue, Jun 14, 2011 at 10:17:10AM +0300, Péter Ujfalusi wrote: > The latency in most cases comes from the fact, that we are running an embedded > system. Number of peripherals are connected via I2C, these drivers are using > workqueues to communicate with the IC. > Since only one device can communicate through I2C at the time. This is > basically the source of the latency. It does not really matter, if the devices > are on the same I2C bus or not, it is enough if two work belonging to device, > which happens to be on the same I2C bus, and the first work in the queue takes > long time to complete (reading back bigger chunk of info, configuring, etc). > Even if we could schedule the second work on the other CPU, it will be put > waiting till the I2C bus is free, so both CPU core has work assigned, the > first is keeping the I2C bus, the other waits for the I2C bus, and the third > is waiting to be scheduled (which will be happening, when the first work > finished). > IMHO the tactile feedback (vibra) should have an excuse to have separate WQ to > avoid latency spikes. > I agree, that most cases we can use the global wq. Thanks for the explanation. I have a couple more questions. * While transferring data from I2C, I suppose the work item is fully occupying the CPU? If so, how long delay are we talking about? Millisecs? * You said that the if one task is accessing I2C bus, the other would wait even if scheduled on a different CPU. Is access to I2C bus protected with a spinlock? Also, as it's currently implemented, single threaded wq's effectively bypass concurrency level control. This is an implementation detail which may change in the future, so even if you're seeing lower latency by using a separate single threaded wq, it's an accident and if you require lower latency you should be expressing the requirement explicitly. Thank you. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
