Re: Re: Re: DSDT in initrd

[Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>]

Hi!

> > > > > What this enables is not only an elimination of the hassle 
> > > > of initrd, it
> > > > > enables previously unmodularizable things like ACPI, or 
> > > > PCI, or all the
> > > > > special code needed for x86 subarchs, or whatever other 
> > > > code that one
> > > > 
> > > > subarchs are different issue. They can't
> > > > be modularized without runtime overhead.
> > > 
> > > How much runtime overhead?
> > 
> > Hard to tell... It might be 10% in heavy-interrupt-load situation...
> 
> Can you help me understand more about why this might be? Why would
> modularized code be a performance hit over statically linked? 

There's a *lot* of small inline functions, look at mach_apic.h. You probably
don't want them to be called using function pointer.

Note note note: I'm not 100% convinced the pointer dereference is
going to be noticable. I guess you have to talk to NUMAQ people to get
the answers...

> I was
> assuming there would be another pointer dereference perhaps but that
> certainly is not going to be noticed. We already have drivers in
> modules, I'm trying to understand how for example a hi-perf nic driver
> performs the same when modularized but subarch stuff wouldn't, when I'm
> assuming it would just be like a "driver" for the particular
> peculiarities of the platform.

Because in each interrupt NIC has to be talked to once, but apic has
to be talked to few times?
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5