On Tuesday 14 June 2011 08:34:00 Tejun Heo wrote:

Yeap, using a separate workqueue doesn't do anything for latency
unless WQ_HIGHPRI and/or WQ_CPU_INTENSIVE is used; however, _please_
stay away from it unless absolutely sure it's necessary (ie. unless
you can pin point to where latency is coming from - even in that case,
the thing which induces the latency probably is the one which should
be fixed).

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.

CMWQ is pretty good at keeping latency low unless something is
consuming large amount of CPU cycles and those work items are marked
WQ_CPU_INTENSIVE, not the other way around and WQ_HIGHPRI is for
things like MCE error reporting.

So this is not really about CPU utilization, it is due to the wide variety of 
peripherals connected to an embedded system.

-- 
Péter