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

[Péter Ujfalusi]

On Tuesday 14 June 2011 10:18:36 Tejun Heo wrote:
> I see, so IIUC,
> 
> * If it's using mutex and not holding CPU for the whole duration, you
>   shouldn't need to do anything special for latency for other work
>   items.  Workqueue code will start executing other work items as soon
>   as the I2C work item goes to sleep.

I see.
 
> * If I2C work item is burning CPU cycles for the whole duration which
>   may stretch to tens / few hundreds millsecs, 1. it's doing something
>   quite wrong, 2. should be marked WQ_CPU_INTENSIVE.
> 
> So, if something needs to be modified, it's the I2C stuff, not the
> vibrator driver.  If I2C stuff isn't doing something wonky, there
> shouldn't be a latency problem to begin with.

In case of OMAP the former is the case regarding to I2C.

However I did run a short experiments regarding to latencies:
With create_singlethread_workqueue :
Jun 14 12:54:30 omap-gentoo kernel: [  211.269531] vibra scheduling time: 30 usec
Jun 14 12:54:30 omap-gentoo kernel: [  211.300811] vibra scheduling time: 30 usec
Jun 14 12:54:33 omap-gentoo kernel: [  214.419006] vibra scheduling time: 31 usec
Jun 14 12:54:34 omap-gentoo kernel: [  214.980987] vibra scheduling time: 30 usec
Jun 14 12:54:35 omap-gentoo kernel: [  215.762115] vibra scheduling time: 30 usec
Jun 14 12:54:35 omap-gentoo kernel: [  215.816650] vibra scheduling time: 30 usec
Jun 14 12:54:35 omap-gentoo kernel: [  215.871337] vibra scheduling time: 61 usec
Jun 14 12:54:35 omap-gentoo kernel: [  215.926025] vibra scheduling time: 61 usec
Jun 14 12:54:35 omap-gentoo kernel: [  215.980743] vibra scheduling time: 61 usec
Jun 14 12:54:35 omap-gentoo kernel: [  216.035430] vibra scheduling time: 61 usec
Jun 14 12:54:38 omap-gentoo kernel: [  219.425659] vibra scheduling time: 31 usec
Jun 14 12:54:40 omap-gentoo kernel: [  220.981658] vibra scheduling time: 31 usec
Jun 14 12:54:44 omap-gentoo kernel: [  224.692504] vibra scheduling time: 30 usec
Jun 14 12:54:44 omap-gentoo kernel: [  225.067138] vibra scheduling time: 30 usec

With create_workqueue :
Jun 14 12:05:00 omap-gentoo kernel: [  304.965393] vibra scheduling time: 183 usec
Jun 14 12:05:01 omap-gentoo kernel: [  305.964996] vibra scheduling time: 61 usec
Jun 14 12:05:03 omap-gentoo kernel: [  307.684082] vibra scheduling time: 152 usec
Jun 14 12:05:06 omap-gentoo kernel: [  310.972778] vibra scheduling time: 30 usec
Jun 14 12:05:08 omap-gentoo kernel: [  312.683715] vibra scheduling time: 61 usec
Jun 14 12:05:10 omap-gentoo kernel: [  314.785675] vibra scheduling time: 183 usec
Jun 14 12:05:15 omap-gentoo kernel: [  319.800903] vibra scheduling time: 61 usec
Jun 14 12:05:16 omap-gentoo kernel: [  320.738403] vibra scheduling time: 30 usec
Jun 14 12:05:16 omap-gentoo kernel: [  320.793090] vibra scheduling time: 61 usec
Jun 14 12:05:16 omap-gentoo kernel: [  320.847778] vibra scheduling time: 61 usec
Jun 14 12:05:16 omap-gentoo kernel: [  320.902465] vibra scheduling time: 61 usec
Jun 14 12:05:16 omap-gentoo kernel: [  320.957153] vibra scheduling time: 61 usec
Jun 14 12:05:16 omap-gentoo kernel: [  320.996185] vibra scheduling time: 31 usec

This is in a system, where I do not have any other drivers on I2C bus, and I have
generated some load with this command:
grep -r generate_load /*

So, I have some CPU, and IO load as well.

At the end the differences are not that big, but with create_singlethread_workqueue
I can see less spikes.

This is with 3.0-rc2 kernel

I still think, that there is a place for the create_singlethread_workqueue, and the
tactile feedback needs such a thing.

As I recall correctly this was the reason to use create_singlethread_workqueue
in the twl4030-vibra driver as well (there were latency issues without it).

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/