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

[Tejun Heo]

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.

-- 
tejun
--
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/