Hello,
On Mon, Jun 13, 2011 at 02:20:28PM -0700, Dmitry Torokhov wrote:
On Mon, Jun 13, 2011 at 12:51:16PM +0300, Péter Ujfalusi wrote:
On Sunday 12 June 2011 01:18:54 Dmitry Torokhov wrote:
+static int twl6040_vibra_open(struct input_dev *input) +{
struct vibra_info *info = input_get_drvdata(input);info->workqueue = create_singlethread_workqueue("vibra");if (info->workqueue == NULL) {dev_err(&input->dev, "couldn't create workqueue\n");return -ENOMEM;}Why do we need to create a separate workqueue? With arrival of CWQ it looks like we should be able to use one of the system-wide workqueues for this.
The reason for this is to ensure that we have the lowest latency as possible in most case. In the embedded devices we use the vibra for tactile type of feedbacks as well, where few tens of ms delay can be felt.
Even if you create a dedicated workqueue with CWQ it will still be using shared pool of threads so I do not think that latency will be affected by using system-wide workqueue. I might be mistaken though, Tejun will correct me if I am wrong...
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).
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.
Thanks.