From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754131AbYIKAh3 (ORCPT ); Wed, 10 Sep 2008 20:37:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752223AbYIKAhR (ORCPT ); Wed, 10 Sep 2008 20:37:17 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:55330 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752168AbYIKAhQ (ORCPT ); Wed, 10 Sep 2008 20:37:16 -0400 Date: Wed, 10 Sep 2008 17:36:30 -0700 From: Andrew Morton To: Robert Hancock Cc: mikhail.kshevetskiy@gmail.com, linux-kernel@vger.kernel.org, aabdulla@nvidia.com, jgarzik@pobox.com Subject: Re: forcedeth: option to disable 100Hz timer (try 2) Message-Id: <20080910173630.d0d38697.akpm@linux-foundation.org> In-Reply-To: <48C863CC.3010902@shaw.ca> References: <48C863CC.3010902@shaw.ca> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 10 Sep 2008 18:18:20 -0600 Robert Hancock wrote: > Andrew Morton wrote: > > On Tue, 9 Sep 2008 23:34:35 +0400 > > Mikhail Kshevetskiy wrote: > > > >> On some hardware no TX done interrupts are generated, thus special > >> 100Hz timer interrupt is required to handle this situation properly. > >> Other device do not require that timer interrupt feature. > >> > >> Forcedeth has a DEV_NEED_TIMERIRQ flag to mark the broken devices. > >> Unfortunately, nobody know the actual list of broken devices, so all > >> device has this flag on. Other problem, this flag is not user visible, > >> so the kernel recompilation is required to disable timer interrupts and > >> test a device. > >> > >> This patch add a "disable_timerirq" option to disable interrupt > >> timer mentioned above. This may be extremely useful for laptop users. > > > > Why do you feel that the timer-based completions need to be disabled? > > Is it causing some problem? > > 100 unnecessary CPU wakeups per second imposes some power usage cost, > especially on laptops with CPU C-states.. Is that the only reason for the change? We still don't know... Anyway, it's certainly _sufficient_ reason, however the implementation is pretty sad - most people won't even know that the option exists so they'll continue to chew more power than they need to. How do we fix this? Perhaps disable the timer by default, then wait for the first tx timeout and then enable the timer at that stage, while printing a message saying "add module option to prevent this once-off timeout from happening"?