LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stephane Eranian <eranian@hpl.hp.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
	Jiri Slaby <jirislaby@gmail.com>, Uwe Bugla <uwe.bugla@gmx.de>,
	akpm@linux-foundation.org, bunk@stusta.de,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>,
	Stephane Eranian <eranian@hpl.hp.com>,
	venkatesh.pallipadi@intel.com
Subject: Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system
Date: Mon, 26 Feb 2007 09:45:53 -0800	[thread overview]
Message-ID: <20070226174553.GD19403@frankl.hpl.hp.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702260906540.12485@woody.linux-foundation.org>

Linus,

On Mon, Feb 26, 2007 at 09:10:22AM -0800, Linus Torvalds wrote:
> > 
> > Side note: this patch adds several function calls (4), several additional 
> > L1 cache touches and a generally inefficient code path to *every single 
> > interrupt that exits from the idle poll*, not to mention the extra (useless, 
> > as it doesn't get used on 99.9% of deployed systems) function call and cache 
> > touches to every single interrupt.
> 
> It is in fact possible that the floppy failure might just be from some 
> timing-dependent thing, and the slowdown itself is the problem.
> 
> Although I do find that a bit unlikely, since machines these days are 
> about a million times faster than they used to be, so even if it's 
> unnecessarily slow, it shouldn't be noticeable for a floppy drive.
> 
I don't know enough about the floppy driver to comment on this but I would
agree with you here.

> >  Keep in mind that systems acting as routers will often be sitting in 
> > the idle loop when processing interrupts.  At the very least this 
> > overhead (which is noticable on profiles) should be configurable.  I 
> > don't think that my 586 class embedded routers really need this crap to 
> > be going into the kernel.
> 
> I'm inclined to agree. Considering that the patch is known to cause 
> problems, and that it's apparently broken on x86 *anyway* (the 
> idle_notifier_register function isn't even exported), and considering that 
> it's clearly bad for interrupt performance and could have been done a lot 
> better, I would suggest just ripping it all out.
> 
The notifier was exported initially but then some people argued I should take
this out because there was no actual users just yet.

As for the performance impact, for non idle tasks, this translates into an
if() return. For the idle, if this is not used, you have a bitop + call
to notifier call chain with empty chain.

With perfmon, we would like to exclude useless kernel execution from being
monitored. That means poll_idle(), default_idle(), mwait_idle(). Yet we
want to capture interrupt handler execution by the idle thread because this
represents useful execution.

The notifier is one mechanism whereby we can dynamically register a callback
to start/stop monitoring to achieve our goal. One could argue the mechanism
is heavy for the usage we make of it. We could certainly add two more
perfmon hooks in the idle code and we would save the atomic call chain notifier
altogether.

Another solution would be to just rely on firmware to stop/restart performance
counters when using mwait or hlt. But we would need something for poll_idle().
An issue with this solution is that it depends on the processor architecture or
implementation, some may not always stop the counters. Yet, we would like to
provide for 'useless execution exclusion' at the interface level for all
architectures. Explicit code may be the only way to provide such guarantee.

If you think there maybe a better way to do this, I am certainly open to suggestions.

Thanks.

-- 
-Stephane

  reply	other threads:[~2007-02-26 17:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-24 17:54 Uwe Bugla
2007-02-24 18:07 ` Andrew Morton
2007-02-24 18:29   ` Uwe Bugla
2007-02-24 19:23   ` Uwe Bugla
2007-02-24 19:49     ` Ray Lee
2007-02-26 10:38 ` Jiri Slaby
2007-02-26 15:12   ` Jiri Slaby
2007-02-26 15:51     ` Linus Torvalds
2007-02-26 16:28       ` Jiri Slaby
2007-02-26 16:34       ` Benjamin LaHaise
2007-02-26 17:10         ` Linus Torvalds
2007-02-26 17:45           ` Stephane Eranian [this message]
2007-02-26 17:28       ` Stephane Eranian
2007-02-26 17:37         ` Linus Torvalds
2007-02-25 18:29 Uwe Bugla
2007-02-25 21:04 ` Alexey Dobriyan
2007-02-26  3:55 ` Mike Galbraith
2007-02-26 18:06 Oleg Nesterov
2007-02-26 18:13 ` Linus Torvalds
2007-02-26 20:55   ` Rene Herman
2007-02-26 21:14     ` Linus Torvalds
2007-02-28  2:42       ` Bill Davidsen
2007-02-28 13:04         ` Alan
2007-02-28 12:20           ` Rene Herman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070226174553.GD19403@frankl.hpl.hp.com \
    --to=eranian@hpl.hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=bcrl@kvack.org \
    --cc=bunk@stusta.de \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=uwe.bugla@gmx.de \
    --cc=venkatesh.pallipadi@intel.com \
    --subject='Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hanging up the whole system' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).