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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Jun 2011 09:31:30 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Péter Ujfalusi <peter.ujfalusi@...com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"Girdwood, Liam" <lrg@...com>, Tony Lindgren <tony@...mide.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"Lopez Cruz, Misael" <misael.lopez@...com>
Subject: 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/