> > this is the main problem why i cant see how we could do the btfixup
> > thing into x86 without losing these optimizations. (and the compiler
> > merges such constant addresses with structure offsets, which makes a
> > theoretical immediate value linker even harder) but maybe it already
> > exists?
>
> Question is how much performance do we lose this way and
> is it worth it or not? I remember people shouting over
> the transition to ELF because it cost 5% performance.
>
> This particular piece of flexibilization probably costs
> FAR less than that (maybe it's even neglectable) and can
> save us (and the poor folks with a 1G+ box) quite a bit
> of headaches and grey hairs...
it's no grey hairs at all. Lets not confuse issues. The only reason 1G
boxes didnt boot on 2.1 was a bug (not missing mechanizm), fixed by a
patch posted here yesterday by Perry Harrington. The rest can be solved by
carefull reintroducing the memory size config option.
your performance argument would have been patently false until recent
kernels, previously almost all kernel source filed had multiple references
to PAGE_OFFSET (through uaccess.h). A recent hack reduced it's usage count
by alot, we now have current->addr_limit (the other reason for that hack
was speed). PAGE_OFFSET is still used quite widely (in about 20% of all
kernel object files), but i agree that PAGE_OFFSET should be runtime on
x86 too, though for a different reason: binary module compatibility ...
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/