Messages in this thread | | | Date | Sun, 6 Dec 1998 13:59:18 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: Problem with 1G RAM |
| |
On Sun, 6 Dec 1998, Rik van Riel wrote:
> > 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/
| |