Linux x86-32 addr space split - Questions

This is a discussion on Linux x86-32 addr space split - Questions ; I've been testing linux 2.6 kernels from some time on x86 32-bit machines. But could not quite get the reason behind the need to split the process address space as 3GB + 1GB (other combinations as well) between kernel and ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Linux x86-32 addr space split

  1. Linux x86-32 addr space split

    I've been testing linux 2.6 kernels from some time on x86 32-bit
    machines. But could not quite get the reason behind the need to split
    the process address space as 3GB + 1GB (other combinations as well)
    between kernel and process-usable ones. Specifically, what is the need
    for PAGE_OFFSET?

  2. Re: Linux x86-32 addr space split

    Mosa Atilles wrote:
    > I've been testing linux 2.6 kernels from some time on x86 32-bit
    > machines. But could not quite get the reason behind the need to split
    > the process address space as 3GB + 1GB (other combinations as well)
    > between kernel and process-usable ones. Specifically, what is the need
    > for PAGE_OFFSET?


    The advantage is that the kernel will have the current process' address
    space as part of its own address space. In a large number of cases, this
    makes expensice copies between separate address spaces (user<->kernel)
    unnecessary.
    Note To stay portable, one should nonetheless use the appropriate
    functions/macros when copying between user and kernel space, even if
    they will then just to a copy.

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


  3. Re: Linux x86-32 addr space split

    Josef Moellers wrote:
    >
    > The advantage is that the kernel will have the current process' address
    > space as part of its own address space. In a large number of cases, this
    > makes expensice copies between separate address spaces (user<->kernel)
    > unnecessary.
    > Note To stay portable, one should nonetheless use the appropriate
    > functions/macros when copying between user and kernel space, even if
    > they will then just to a copy.
    >


    Thanks Josef. That certainly does reduce a lot of overhead.
    But then there is only so much kernel address space to accommodate the
    various kernel data structs (pte, vma etc). That in turn constrains the
    amount of shared memory that can be mapped into the process addr space.
    I guess it's a trade-off in favour of performance.
    Thanks again, for imparting that clarity.

  4. Re: Linux x86-32 addr space split

    Josef Moellers writes:

    >The advantage is that the kernel will have the current process' address=20
    >space as part of its own address space. In a large number of cases, this =


    >makes expensice copies between separate address spaces (user<->kernel)=20
    >unnecessary.


    The copies are still necessary, they're just cheaper because you read/write
    to the same address space.

    >Note To stay portable, one should nonetheless use the appropriate=20
    >functions/macros when copying between user and kernel space, even if=20
    >they will then just to a copy.


    That's not just about portability; referencing user data from the
    kernel directly may cause a page fault which won't generally be handled
    by the kernel (typically, it won't generate a page fault because system
    calls are typically handed data which has just been touched).

    When Solaris for UltraSPARC was done, the kernel and userland got
    a separate address space as the CPU supports that cheaply. This
    flushed out a number of those bugs. If you tried hard, you could
    make the kernel panic abusing those bugs before, but nobody noticed
    (or they were written of as transient failures)

    Casper

  5. Re: Linux x86-32 addr space split

    Casper H.S. Dik wrote:
    > Josef Moellers writes:
    >
    >
    >>The advantage is that the kernel will have the current process' address=20
    >>space as part of its own address space. In a large number of cases, this =

    >
    >
    >>makes expensice copies between separate address spaces (user<->kernel)=20
    >>unnecessary.

    >
    >
    > The copies are still necessary, they're just cheaper because you read/write
    > to the same address space.


    That's why I wrote "expensive copies". The grouping probably got lost
    somwhere between a couple of synapses and the keyboard.

    >>Note To stay portable, one should nonetheless use the appropriate=20
    >>functions/macros when copying between user and kernel space, even if=20
    >>they will then just to a copy.

    >
    >
    > That's not just about portability; referencing user data from the
    > kernel directly may cause a page fault which won't generally be handled
    > by the kernel (typically, it won't generate a page fault because system
    > calls are typically handed data which has just been touched).


    ACK. I totally forgot about that.
    Blindly copying data between user and kernel address spaces generates
    all sorts of problems, not only can a page fault occur, but also the
    user might specify some illegal (and dangerous) address.

    --
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize
    -- T. Pratchett


+ Reply to Thread