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
next prev parent 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).