Return-path: Received: from mail-iw0-f204.google.com ([209.85.223.204]:35045 "EHLO mail-iw0-f204.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752220AbZIGW7I (ORCPT ); Mon, 7 Sep 2009 18:59:08 -0400 MIME-Version: 1.0 From: "Luis R. Rodriguez" Date: Mon, 7 Sep 2009 15:58:50 -0700 Message-ID: <43e72e890909071558s637b45c7i10807587dc40e8c4@mail.gmail.com> Subject: Stop using tasklets for bottom halves To: Steven Rostedt , Ingo Molnar , Michael Buesch , "John W. Linville" Cc: linux-wireless , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Matt Smith , Kevin Hayes , Bob Copeland , Jouni Malinen , Ivan Seskar , ic.felix@gmail.com Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: A while ago I had read about an effort to consider removing tasklets [1] or at least trying to not use them. I'm unaware of the progress in this respect but since reading that article have always tried to evaluate whether or not we need tasklets on wireless drivers. I have also wondered whether work in irq context in other parts of the kernel can be moved to process context, a curious example being timers. I'll personally be trying to using only process context on bottom halves on future drivers but I figured it may be a good time to ask how serious was avoiding tasklets or using wrappers in the future to avoid irq context is or is it advised. Do we have a general agreement this is a good step forward to take? Has anyone made tests or changes on a specific driver from irq context to process context and proven there are no significant advantages of using irq context where you would have expected it? Wireless in particular should IMHO not require taskets for anything time sensitive that I can think about except perhaps changing channels quickly and to do that appropriately also process pending RX frames prior to a switch. It remains to be seen experimentally whether or not using a workqueue for RX processing would affect the time to switch channels negatively but I doubt it would be significant. I hope to test that with ath9k_htc. What about gigabit or 10 Gigabit Ethernet drivers ? Do they face any challenges which would yet need to be proven would not face issues when processing bottom halves in process context? [1] http://lwn.net/Articles/239633/ Luis