netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: David Howells <dhowells@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	john stultz <johnstul@us.ibm.com>, Adrian Bunk <bunk@stusta.de>,
	Andrew Morton <akpm@osdl.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	linux-kernel@vger.kernel.org, Jeff Garzik <jeff@garzik.org>,
	netdev@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
Date: Thu, 7 Sep 2006 12:26:21 +0200	[thread overview]
Message-ID: <20060907102621.GC4125@elte.hu> (raw)
In-Reply-To: <8934.1157622928@warthog.cambridge.redhat.com>


* David Howells <dhowells@redhat.com> wrote:

> The genirq subdir all wraps up into this:
> 
> 	  10908    3272      12   14192    3770 kernel/irq/built-in.o
> 	   1548      64       4    1616     650 arch/frv/kernel/irq.o
> 	---------------------------------------------------------------------
> 	  12456    3336      16   15808    3dc0 total

hm, could you take a look at why that difference happens? Do you make 
use of __do_IRQ()? Do you make use of all the various flow handlers that 
are offered in handle.c? Could you #ifdef out all the functions that are 
unused? The kernel build process doesnt remove them and i havent (yet) 
put them into a library.

Could you please send us the patch that genirq-ifies FRV?

> So, again, why _should_ I use the generic IRQ stuff? [...]

To have shared code between architectures? To make generic API updates 
easier for all of us? To have less cruft in interrupt.h? To not having 
to add last-minute patches to v2.6.18 because some arch defines its own 
IRQ prototypes and a difficult generic feature like irqtrace breaks? To 
get new IRQ subsystem features for free like preemptible irqs, irqpoll 
or SHIRQ debugging?

the same "why should we share code" argument could be made for the VFS 
too. Sharing code has a (small) price most of the time, but it's also 
very much worth it. I think the size increases you are seeing are 
artificial and most of it is not caused by the indirections. If they 
were caused by the indirections i'd probably agree with you.

if your argument were true every arch should run its whole Linux kernel 
in arch/frv, with zero sharing with anyone else. There's always a lot of 
'unnecessary' stuff all around the kernel that is just a hindrance for 
FRV. In reality what makes us stronger is to work together. I dont for a 
minute say that we should overdo code sharing - if it's not possible 
then it must not be forced, but just the pure fact of "more 
indirections" or "what does this bring me _now_" isnt a good enough 
reason i believe - it simply makes _future_ changes easier.

	Ingo

  reply	other threads:[~2006-09-07 10:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060901015818.42767813.akpm@osdl.org>
2006-09-05 13:25 ` 2.6.18-rc5-mm1: {dis,en}able_irq_lockdep_irqrestore compile error Adrian Bunk
2006-09-05 15:21   ` [PATCH] FRV: Fix " David Howells
2006-09-06 12:50     ` Ingo Molnar
2006-09-05 15:27   ` [PATCH] NOMMU: Move the fallback arch_vma_name() to a sensible place David Howells
2006-09-05 15:29   ` [PATCH] NOMMU: Provide page_mkclean() for NOMMU David Howells
2006-09-05 15:31   ` [PATCH] NOMMU: Make lib/ioremap.c conditional David Howells
2006-09-05 15:35   ` [PATCH] FRV: do_gettimeofday() should no longer use tickadj David Howells
2006-09-06  1:46     ` john stultz
2006-09-06  9:27       ` David Howells
2006-09-06  9:43         ` Ingo Molnar
2006-09-06 12:30           ` David Howells
2006-09-06 12:56             ` Ingo Molnar
2006-09-06 14:46               ` David Howells
2006-09-06 23:01                 ` Benjamin Herrenschmidt
2006-09-07  9:55                   ` David Howells
2006-09-07 10:26                     ` Ingo Molnar [this message]
2006-09-07 13:34                       ` David Howells
2006-09-07 22:53                     ` Benjamin Herrenschmidt
2006-09-08 10:25                       ` David Howells
2006-09-08 11:05                         ` Benjamin Herrenschmidt
2006-09-08 12:24                           ` David Howells
2006-09-08 12:29                       ` David Howells
2006-09-11  4:06                         ` Benjamin Herrenschmidt
2006-09-09  5:46                 ` Ingo Molnar
2006-09-11 10:46                   ` David Howells

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=20060907102621.GC4125@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@osdl.org \
    --cc=arjan@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=bunk@stusta.de \
    --cc=dhowells@redhat.com \
    --cc=jeff@garzik.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).