Re: [patch 1/1] unified spinlock initialization arch/um/drivers/port_kern.c
From: Russell King
Date: Wed Mar 09 2005 - 23:51:03 EST
On Wed, Mar 09, 2005 at 08:52:24PM +0100, Blaisorblade wrote:
> On Wednesday 09 March 2005 18:12, Russell King wrote:
> > On Wed, Mar 09, 2005 at 10:42:33AM +0100, blaisorblade@xxxxxxxx wrote:
> > > From: <domen@xxxxxxxxxxxx>
> > > Cc: <user-mode-linux-devel@xxxxxxxxxxxxxxxxxxxxx>, <domen@xxxxxxxxxxxx>,
> > > <amitg@xxxxxxxxxxxxxx>, <gud@xxxxxxx>
> > >
> > > Unify the spinlock initialization as far as possible.
> > Are you sure this is really the best option in this instance?
> > Sometimes, static data initialisation is more efficient than
> > code-based manual initialisation, especially when the memory
> > is written to anyway.
> Agreed, theoretically, but this was done for multiple reasons globally, for
> instance as a preparation to Ingo Molnar's preemption patches. There was
> mention of this on lwn.net about this:
Was this announced on linux-kernel as well? I don't remember seeing it.
I'm not convinced about the practicality of converting all static
initialisations to code-based initialisations though - I can see
that the number of initialisation functions scattered throughout
the kernel is going to increase dramatically to achieve this.
With a 2.4 to 2.6 kernel bloat already on the order of 140% for
similar functionality, I can only see the kernel getting more and
more bloated _for the same feature level_ because we're trying to
add more features to the kernel.
I'm not entirely convinced that is an all round sane approach.
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/