On Fri, 29 Jun 2007, Alexey Kuznetsov wrote:
quoted text
> Hello!
>
> > I find the 4usecs cost on a P4 interesting and a bit too high - how did
> > you measure it?
>
> Simple and stupid:

Noted ;-)

quoted text
> static void measure_tasklet0(void)
> {
> 	int i;
> 	int cnt = 0;
> 	DECLARE_TASKLET(test, do_test, 0);
> 	unsigned long start = jiffies;

Not a very accurate measurement (jiffies that is).

quoted text
>
> 	for (i=0; i<1000000; i++) {
> 		flag = 0;
> 		local_bh_disable();
> 		tasklet_schedule(&test);
> 		local_bh_enable();
> 		while (flag == 0) {
> 			schedule();
> 			cnt++;
> 		} /*while (flag == 0)*/;
> 	}
> 	printk("tasklet0: %lu %d\n", jiffies - start, cnt);
> }
>

[...]

quoted text
>
> static void measure_workqueue(void)
> {
> 	int i;
> 	int cnt = 0;
> 	unsigned long start;
> 	DECLARE_WORK(test, do_test_wq, 0);
> 	struct workqueue_struct * wq;
>
> 	start = jiffies;
>
> 	wq = create_workqueue("testq");
>
> 	for (i=0; i<1000000; i++) {
> 		flag = 0;
> 		queue_work(wq, &test);
> 		do {
> 			schedule();

Since the work queue *is* a thread, you are running a busy loop here. Even
though you call schedule, this thread still may have quota available, and
will not yeild to the work queue.  Unless ofcourse this caller is of lower
priority. But even then, I'm not sure how quickly the schedule would
choose the work queue.



 > 			cnt++;
quoted text
> 		} while (flag == 0);
> 	}
> 	printk("wq: %lu %d\n", jiffies - start, cnt);
> 	destroy_workqueue(wq);
> }
>
>
>

quoted text
> and is easy to remove.
>
> It is sad that some usb drivers started to use this creepy and
> useless thing.
>
>
> > also, the "be afraid of the hardirq or the process context" mantra is
> > overblown as well. If something is too heavy for a hardirq, _it's too
> > heavy for a tasklet too_. Most hardirqs are (or should be) running with
> > interrupts enabled, which makes their difference to softirqs miniscule.
>
> Incorrect.
>
> The difference between softirqs and hardirqs lays not in their "heavyness".
> It is in reentrancy protection, which has to be done with local_irq_disable(),
> unless networking is not isolated from hardirqs. That's all.
> Networking is too hairy to allow to be executed with disabled hardirqs.
> And moving this hairyiness to process context requires
> <irony mode> a little </> more efforts than conversion tasklets to work queues.
>

I do really want to point out something in the Subject line. **RFC**
:-)

I had very little hope for this magic switch to get into mainline. (maybe
get it into -mm)  But the thing was is that tasklets IMHO are over used.
As Ingo said, there are probably only 2 or 3 places in the kernel that a
a switch to work queue conversion couldn't solve. Those places could then
probably be solved by a different design (yes that would take work).

Tasklets are there and people will continue to use them when they
shouldn't for as long as they exist. Tasklets are there because there
wasn't work queues or kthreads at the time of solving the solution that
tasklets solved.

So if you can still keep the same performance without tasklets, I say we
get rid of them. I've also meet too many device driver writers that want
the lowest possible latency for their device, and do so by sacrificing the
latency of other things in the system that may be even more critical.

Also note, that the more tasklets we have, the higher the latency will be
for other tasklets. There's only two prios you can currently give a
tasklet, so competing devices will need to fight each other without the
admin being able to have as much control over the result.

-- Steve

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