Re: Re: Re: [PATCH v4 11/18] input: Add initial support for TWL6040 vibrator

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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html