On Friday 29 September 2006 22:14, Ingo Molnar wrote:
>
> * Andi Kleen <[email protected]> wrote:
>
> > BTW I was planning to make LOCAL_APIC unconditional on i386 too like
> > on x86-64.
>
> please dont - embedded doesnt need it most of the time.
What do you mean with not need? Local APIC is an infinitely better
interface than PIC and faster. On embedded too this makes a lot of sense.
And a lot of modern systems don't even work anymore without
APIC enabled because Windows uses it and the BIOS haven't been
tested without it (e.g. you often find totally broken code paths
in the AML for PIC mode)
The code size also isn't a good argument because the delta
isn't that big:
text data bss dec hex filename
3303894 694980 436420 4435294 43ad5e obj32-up/vmlinux
3266532 665732 402372 4334636 42242c obj32-up-noapic/vmlinux
~63K. I don't think such a small difference is worth the maintenance
overhead of the many ifdefs and hairy code paths. If someone really
cared about that memory they could save much more by just optimizing
some dynamic memory allocations instead, which waste much more.
The only reason to not use it are old broken BIOS or old CPUs
without local APIC, but those can be all handled at runtime like
the 64bit kernel does.
The SUSE kernel has a imho good default heuristic based on
DMI date, DMI number of processors and of course trusting the ACPI tables
(don't use if disabled there)
> At most make it
> default y and dependent on EMBEDDED.
The whole point is to get rid of the many ifdefs and frequent
compile breakage of it. This would defeat it.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
