All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Karsten Wiese <annabellesgarden@yahoo.de>
Cc: Alexander Nyberg <alexn@telia.com>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] CHECK_IRQ_PER_CPU() to avoid dead code in __do_IRQ()
Date: Mon, 08 Aug 2005 08:51:03 -0700	[thread overview]
Message-ID: <42F77F67.8070602@vmware.com> (raw)
In-Reply-To: <200508081736.10690.annabellesgarden@yahoo.de>

Karsten Wiese wrote:

>Am Montag, 8. August 2005 13:19 schrieb Alexander Nyberg:
>  
>
>>There are many places where one could replace run-time tests with 
>>#ifdef's but it makes reading more difficult (and in longer terms
>>maintainence). Have you benchmarked any workload that benefits 
>>from this?
>>    
>>
>
>Performance gain is small, but measurable: 0,02%
>Tested on an Atlon64 running at 1000MHz.
>I took this value from 9 runs (each with/without the patch) of 
>	$ time lame x.wav
>where each took about 1 minute.
>3000 Interrupts/s were generated at the time by running
>	$ jackd -R -dalsa -p64 -n2
>
>0,02% really isn't that much....but Athlon64 is better than P4
>with branch predictions, I think.
>
>Erm... ok, I won't insist on having this patch applied ;-) 
>
>   Karsten
>  
>

Removing dead code is always good - 0.02% is small, but if 100 kernel 
developers all did the same, that adds up to 2% rather quickly, and that 
is nothing to sneeze at.  I like your patch, but you should add some 
comments for maintainability about what CHECK_IRQ_PER_CPU does - see 
include/asm-generic/pgtable.h for similar styling.  If also probably 
doesn't hurt to leave IRQ_PER_CPU defined even when 
ARCH_HAS_CHECK_IRQ_PER_CPU is not, since it looks cleaner and prevents 
future collisions with bits defined inside of an #ifdef.

Zach

  reply	other threads:[~2005-08-08 15:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-08 10:50 [PATCH] CHECK_IRQ_PER_CPU() to avoid dead code in __do_IRQ() Karsten Wiese
2005-08-08 11:19 ` Alexander Nyberg
2005-08-08 15:36   ` Karsten Wiese
2005-08-08 15:51     ` Zachary Amsden [this message]
2005-08-09 14:10   ` Zwane Mwaikambo

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=42F77F67.8070602@vmware.com \
    --to=zach@vmware.com \
    --cc=alexn@telia.com \
    --cc=annabellesgarden@yahoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.