[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4683EF50.30108@garzik.org>
Date:	Thu, 28 Jun 2007 13:26:40 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>
CC:	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@...radead.org>,
	john stultz <johnstul@...ibm.com>,
	Oleg Nesterov <oleg@...sign.ru>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	"David S. Miller" <davem@...emloft.net>, matthew.wilcox@...com
Subject: Re: [RFC PATCH 0/6] Convert all tasklets to workqueues
Ingo Molnar wrote:
> my argument was: workqueues are more scalable than tasklets in general.
Here is my argument:  that is totally irrelevant to $subject, when it 
comes to dealing with managing existing [network driver] behavior and 
performance.
My overall objection is the attempt to replace apples with oranges.
Network drivers use tasklets TODAY.  Each driver -- in particular 
acenic, ns83820, and the 10Gbps drivers -- has been carefully tuned to 
use tasklets, hardirqs, and perhaps NAPI too.  Changing to workqueue 
WILL affect network driver hot paths, yet I see no analysis or 
measurement at all of the behavior differences.
If hackers are willing to revisit each network driver, rework the 
tasklet code to something more sane [in your opinion], and TEST it, I 
will review the patches and happily ACK away.
Given that I feel that course of action is unlikely (the preferred 
alternative apparently being "I don't use these drivers, but surely my 
changes are OK anyway"), I do not see how this effort can proceed as is.
Lots of time went into tuning these network drivers for the specific 
thread model they use.  Maybe that thread model is no longer in style. 
Maybe modern machine behavior dictates a different approach.  The point 
is... you don't know.
	Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Powered by blists - more mailing lists
 
