From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: John Hawkes <hawkes@sgi.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org,
lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] [PATCH] drop note_interrupt() for per-CPU for proper scaling
Date: Thu, 26 May 2005 12:22:12 -0700 [thread overview]
Message-ID: <20050526192212.GB1298@us.ibm.com> (raw)
In-Reply-To: <4295081B.MailKJ51120GH@jackhammer.engr.sgi.com>
On Wed, May 25, 2005 at 04:19:55PM -0700, John Hawkes wrote:
> The "unhandled interrupts" catcher, note_interrupt(), increments a global
> desc->irq_count and grossly damages scaling of very large systems, e.g.,
> >192p ia64 Altix, because of this highly contented cacheline, especially
> for timer interrupts. 384p is severely crippled, and 512p is unuseable.
>
> All calls to note_interrupt() can be disabled by booting with "noirqdebug",
> but this disables the useful interrupt checking for all interrupts.
>
> I propose eliminating note_interrupt() for all per-CPU interrupts.
> This was the behavior of linux-2.6.10 and earlier, but in 2.6.11 a
> code restructuring added a call to note_interrupt() for per-CPU interrupts.
> Besides, note_interrupt() is a bit racy for concurrent CPU calls anyway,
> as the desc->irq_count++ increment isn't atomic (which, if done, would make
> scaling even worse).
Would it be reasonable for note_interrupt() to operate on per-CPU or
per-group-of-CPUs counters? Each CPU (or group) could either separately
count and check, or, if accuracy is important (can't see why it would
be), the per-CPU (or group) counters could be added to a global counter
every 100 (or 1,000 or whatever) counts, and this global counter then
checked against the limit.
Thanx, Paul
> Signed-off-by: John Hawkes <hawkes@sgi.com>
> ---
>
> Index: linux/kernel/irq/handle.c
> ===================================================================
> --- linux.orig/kernel/irq/handle.c 2005-03-01 23:38:37.000000000 -0800
> +++ linux/kernel/irq/handle.c 2005-05-18 11:02:18.000000000 -0700
> @@ -118,8 +118,6 @@
> */
> desc->handler->ack(irq);
> action_ret = handle_IRQ_event(irq, regs, desc->action);
> - if (!noirqdebug)
> - note_interrupt(irq, desc, action_ret);
> desc->handler->end(irq);
> return 1;
> }
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
> online with coworkers and clients while avoiding the high cost of travel and
> communications. There is no equipment to buy and you can meet as often as
> you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
> _______________________________________________
> Lse-tech mailing list
> Lse-tech@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lse-tech
>
prev parent reply other threads:[~2005-05-26 19:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-25 23:19 John Hawkes
2005-05-26 19:22 ` Paul E. McKenney [this message]
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=20050526192212.GB1298@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=akpm@osdl.org \
--cc=hawkes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®