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

[Tejun Heo <tj@kernel.org>]

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