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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
