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).