linux-kernel - Re: 2.6.18-mm2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200609292236.15330.ak@suse.de>
Date:	Fri, 29 Sep 2006 22:36:15 +0200
From:	Andi Kleen <ak@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jim Cromie <jim.cromie@...il.com>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.18-mm2

On Friday 29 September 2006 22:14, Ingo Molnar wrote:
> 
> * Andi Kleen <ak@...e.de> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/