lkml.org 
[lkml]   [1998]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
FromPerry Harrington <>
SubjectRe: Problem with 1G RAM
DateFri, 4 Dec 1998 14:58:51 -0800 (PST)
> matter of running out of kernel + user address space.  In these
> sparc32 cases the PAGE_OFFSET is set dynamically at boot time based
> upon how much memory is in the machine.

Wouldn't making PAGE_OFFSET a variable be a win on x86 too? Consider this:

For every operation involving PAGE_OFFSET, an immediate value must be loaded
as part of an equation. If we made it a variable, GCC, in combination with
the CPU could keep the PAGE_OFFSET register resident (on older chips it could
not be a big win, but on chips that do register aliasing and such, it could
be an even bigger win) or at the minimum, cache resident.

Assuming the following sequence:

calculate an address involving PAGE_OFFSET;
do some other addition with register results;
store;
calculate an address involving PAGE_OFFSET;

With the above, a PPro could do OOOE and SE, and reuse a single register.
Otherwise it would involve 2 loads (just for the sake of argument).

On a 386, it would be similar in both cases, unless more work took place
between operations, in which a reload would take place and a cache could
be used for that.

mov cx, PAGE_OFFSET immediate
mov ax, value
mul cx
mov bx, value
add bx, ax
mov [blah], bx
mov ax, value
mul cx

Does any of this make sense? Or am I just off my rocker? I thought of dynamicising
PAGE_OFFSET for x86, but I figured that Linus, et al, would have a fit over performance.

>
> Later,
> David S. Miller
> davem@dm.cobaltmicro.com
>

--Perry

--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2010