32 bit OS, 4 GB limit? - Ubuntu

This is a discussion on 32 bit OS, 4 GB limit? - Ubuntu ; phil-news-nospam@ipal.net wrote: > There's nothing the PAE design that would prevent a 32-bit PAE system from > remapping the lost 0.75GB of RAM into a location above the 4GB address as > long as the system is not fully populated ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 50 of 50

Thread: 32 bit OS, 4 GB limit?

  1. Re: 32 bit OS, 4 GB limit?

    phil-news-nospam@ipal.net wrote:

    > There's nothing the PAE design that would prevent a 32-bit PAE system from
    > remapping the lost 0.75GB of RAM into a location above the 4GB address as
    > long as the system is not fully populated to the PAE limit of 64GB. However,
    > the real question is whether or not real implementations have been made to
    > do just that.
    >
    > I have a Tyan S2927A2NRF board (2 sockets of dual-core AMD Opeteron CPUs)
    > with 8GB of RAM installed. Kernel messages at boot are not all that clear,
    > given a variety of different numbers. But at least one number in one place,
    > and the sum of 2 numbers in another place which add up to exactly the same
    > thing, give an effective memory of 8.625 GB based on powers of 1024. Other
    > numbers might be memory available beyond what is used initially by the kernel.
    >
    > [ 0.000000] 7936MB HIGHMEM available.
    > [ 0.000000] 896MB LOWMEM available.
    >
    > [ 53.151597] Memory: 8310416k/9043968k available (3399k kernel code, 76920k reserved, 1281k data, 228k init, 7470912k highmem)
    > [ 53.151684] virtual kernel memory layout:
    > [ 53.151685] fixmap : 0xfff4d000 - 0xfffff000 ( 712 kB)
    > [ 53.151686] pkmap : 0xffc00000 - 0xffe00000 (2048 kB)
    > [ 53.151687] vmalloc : 0xf8800000 - 0xffbfe000 ( 115 MB)
    > [ 53.151687] lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
    > [ 53.151688] .init : 0xc059b000 - 0xc05d4000 ( 228 kB)
    > [ 53.151689] .data : 0xc0451cce - 0xc0592374 (1281 kB)
    > [ 53.151690] .text : 0xc0100000 - 0xc0451cce (3399 kB)
    >

    Mine is somewhat like that. I have SuperMicro X5DP8-G2 motherboard (two
    sockets with hyperthreaded Xeon processors), 8 GBytes RAM. Red Hat
    Enterprise Linux 5.2 OS.

    Jun 25 14:40:31 trillian kernel: 7424MB HIGHMEM available.
    Jun 25 14:40:31 trillian kernel: 896MB LOWMEM available.

    Jun 25 14:40:32 trillian kernel: Memory: 8181816k/8519680k available (2093k
    kernel code, 204992k reserved, 873k data, 228k init, 7470528k highmem)

    I do not get virtual kernel memory layout.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 11:05:01 up 18 days, 20:25, 6 users, load average: 4.56, 4.34, 4.33

  2. Re: 32 bit OS, 4 GB limit?

    de Kameel wrote:
    > Ian Pawson wrote:
    >
    >> Mike Smith wrote:
    >>> On Fri, 11 Jul 2008 16:31:49 +0100, Ian Pawson wrote:
    >>>
    >>>> Install the PAE kernel and it should all be available.
    >>> Can you do that on workstation or only in the server version?

    >> Yes, works on the 'desktop' version. Not greater than 4GB though.

    >
    > Please explaing that? The whole idea of PAE is ... using more than 4GB
    > memory. Quote from http://en.wikipedia.org/wiki/Physical_Address_Extension
    >
    > "In computing, Physical Address Extension (PAE) refers to a feature of x86
    > and x86-64 processors that allows more than 4 gigabytes (GB) of physical
    > memory to be used in 32-bit systems, given appropriate operating system
    > support."
    >
    > de Kameel
    >

    Sorry, I missed out a word. I meant to say that 'I had not tried it with
    more than 4gb' which is all my mobo will take. Sorry for any confusion

  3. Re: 32 bit OS, 4 GB limit?

    General Schvantzkopf wrote:
    >
    >> Now the other end of the nuance is how much physical memory a 32-bit
    >> system can see? If you have 4GB of RAM installed on a 32-bit system,
    >> then your system will only see upto 3.25GB of that 4GB. The remaining
    >> RAM is ignored because it is used for peripheral hardware such as video
    >> cards, ROM, and other stuff. I think this is a problem on 32-bit
    >> systems, in that they will always lop that extra 0.75GB of memory from
    >> system usage, even if you have 8 or 16GB of RAM installed (so you'll
    >> only see 7.25GB or 15.25GB). This won't be a problem on 64-bit systems,
    >> they can typically remap all of the system RAM to higher locations.
    >>
    >> Yousuf Khan

    >
    > 32 bit PAE kernels don't lop off anything, if you have 4G of RAM all of
    > it will be available to the system although only 3G will be available to
    > any individual thread. If the kernel is compiled with regular 32 bit
    > addressing instead or PAE then it will have to map the IO space into the
    > top of it's 4G address space which will limit the RAM to less than 4G.
    > There can also be a BIOS issue with early AMD64 systems. In those BIOSes
    > you had to explicitly enable something called Memory Hole Remapping which
    > would move the IOMMU above the RAM space, if you didn't do that then even
    > a 64 bit kernel couldn't see all of the RAM. I don't know if there are
    > any current BIOSes that still make Memory Hole Remapping an option, I
    > think they just do what needs to be done so that all of the RAM is
    > accessible.
    >
    > 32 bit Linux distros all have PAE kernels available so there is no reason
    > that any Linux user would be able to use all of the RAM in their system.
    > Windows users don't have that luxury. 32 bit XP and 32 bit Vista are
    > compiled without PAE so users of those OSes are limited to less than 4G
    > of RAM. Obviously 64 bit XP and Vista can access all of their RAM.


    And that's another one of the many horrors of using Windows. Pay extra
    (for a 64 bit OS, and obviously the hardware too) or there are hidden
    catches. Switch to Linux and you get all of the extra features you pay
    for with Windows for absolutely free.

  4. Re: 32 bit OS, 4 GB limit?

    At 14 Jul 2008 13:34:28 GMT phil-news-nospam@ipal.net wrote:

    >
    > In comp.os.linux.misc Robert Heller wrote:
    >
    > | At 13 Jul 2008 13:55:54 GMT phil-news-nospam@ipal.net wrote:
    > |
    > |>
    > |> In comp.os.linux.misc Ben wrote:
    > |> | phil-news-nospam@ipal.net wrote:
    > |> |> In comp.os.linux.misc Ben wrote:
    > |> |> | curiousdave@AOL.com wrote:
    > |> |> |> Is that correct that the sum total of all virtual memory allocations
    > |> |> |> on a 32 bit OS cannot exceed 4 GB?
    > |> |> |>
    > |> |> |> For example, if I have 4 GB of RAM, can I run 20 programs that take 500
    > |> |> |> MB each? (with most memory swapped out, and big swap file, of course).
    > |> |> |>
    > |> |> |> Also, is it true that 32 bit install cannot use more than 4 GB of
    > |> |> |> physical RAM?
    > |> |> |>
    > |> |> |> Dave
    > |> |> |
    > |> |> | This problem was solved with Physical Address Extension. As long as both
    > |> |> | your CPU (nearly all modern 32-bit CPUs do now) and your kernel supports
    > |> |> | PAE, and the mainline Linux kernel does now, then you should be easily
    > |> |> | able to run up to 64GB RAM.
    > |> |>
    > |> |> Beyond that, things should be shifting to 64-bit. But can we have a 32-bit
    > |> |> virtual address space on a 64-bit kernel?
    > |> |>
    > |> |
    > |> | Everything is backwards compatible with 32 bit anyways, so that's not a
    > |> | problem.
    > |>
    > |> But that's not an answer to my question. If I bring up a 64-bit kernel, will
    > |> it DIRECTLY run /sbin/init and all other processes started from there from a
    > |> 32-bit root file system tree? IOW, will 32-bit ABI syscalls still work from
    > |> within a 32-bit virtual address space?
    > |
    > | The 32-bit PAE kernels are 32-bit kernels, with kernel mode mapping
    > | magic to allow a 36-bit virtual address space. *User Mode* processes won't
    > | even be aware that more then 4gig of address space even exists. This is
    > | NOT a true 64-bit kernel.
    > |
    > | If you have a true 64-bit processor and not just a i686 with PAE, but a
    > | x86_64 or i64 processor, AND you want a full 64-bit system, then you
    > | need to install a full 64-bit *distribution*, which will include a
    > | 64-bit kernel, plus a full set of 64-bit base system utilities. Most
    > | (all?) such distros also include the 32-bit shared libraries, which
    > | means that 32-bit x86 (i32) programs will also be runable -- the kernel
    > | / program loader will set them up with a 32-bit address space and the
    > | resulting processes behave just like they are running on a generic
    > | 32-bit i686.
    >
    > However, these 32-bit compatibility libraries in the 64-bit distribution could
    > be converting the 32-bit library-calling-ABI into the 64-bit syscall-ABI and
    > interacting with the kernel on a 64-bit level.


    No, they don't do that -- I don't think they can. There are no '32-bit
    compatibility libraries', they are just the 32-bit libraries. When a
    32-bit program in running, that process is 'locked' in 32-bit
    processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
    level, at least in *user mode*. The 32-bit libraries are the *same*
    32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
    installed 32-bit libraries from a 32-bit distro on a 64-bit system
    (running a 64-bit kernel) [I had an old 32-bit program that used old
    shared libraries and it was too much trouble to mess with re-building it
    on the 64-bit box]. The 32-bit libraries use the 32-bit
    library-calling-ABI, just like on a 32-bit i[3456]86 system. The
    *kernel* runs in 64-bit mode and has access to the 64-bit address
    space, in *kernel* mode.

    >
    > My question was NOT "can I run a 32-bit dynamically linked application
    > executable run on a 64-bit Linux distribution (that has 32-bit compatibility
    > libraries)?".


    There is no such thing as '32-bit compatibility libraries'. The x86_64
    processor can run as a ia32 (eg i686) processor and can run 32-bit
    programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
    processor bit (or whatever) to put it into the proper 'mode'.

    >
    > My question IS "can a complete 32-bit root tree, with 32-bit libraries that
    > work on a 32-bit kernel, and many 32-bit statically linked executables, work
    > on a 64-bit kernel?".


    Very likely they will run, but why? If you are just going to run a
    32-bit system, install a 32-bit kernel. If you are going to install a
    64-bit kernel, you might as well install a 64-bit root tree.

    >
    > The question might need to be extended in the case of virtualization such as
    > Xen. But until someone grasps the conceptual difference between running a
    > 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
    > running a 32-bit executable with 32-bit to 64-bit compatibility libraries

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    THERE IS NO SUCH THING!!! GET THIS OUT
    OUT OF YOUR MIND!!!!!!!!!!!

    > under a 64-bit kernel, I shall try to keep the question simple in the hopes
    > of actually getting an answer from someone who actually knows whether or not
    > this concept matters for 32-bit kernels vs. 64-bit kernels on at least the
    > x86-64 hardware architecture.


    The virtualization systems (eg Xen) handle all of this. I am sure that
    if you install a 64-bit virtualization system on a 64-bit system and
    have it provide a batch of virtual 32-bit systems, it will work just
    fine -- each of the virtual 32-bit systems will have a 32-bit kernel.

    You can *probably* install and run a 32-bit version of the
    virtualization system (eg Xen), but why would you do this on a 64-bit
    system with a 64-bit kernel?

    What *exactly* are you trying to achieve here?

    >


    --
    Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
    Deepwoods Software -- Linux Installation and Administration
    http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
    heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

  5. Re: 32 bit OS, 4 GB limit?

    In comp.os.linux.misc Robert Heller wrote:

    | No, they don't do that -- I don't think they can. There are no '32-bit
    | compatibility libraries', they are just the 32-bit libraries. When a
    | 32-bit program in running, that process is 'locked' in 32-bit
    | processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
    | level, at least in *user mode*. The 32-bit libraries are the *same*
    | 32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
    | installed 32-bit libraries from a 32-bit distro on a 64-bit system
    | (running a 64-bit kernel) [I had an old 32-bit program that used old
    | shared libraries and it was too much trouble to mess with re-building it
    | on the 64-bit box]. The 32-bit libraries use the 32-bit
    | library-calling-ABI, just like on a 32-bit i[3456]86 system. The
    | *kernel* runs in 64-bit mode and has access to the 64-bit address
    | space, in *kernel* mode.

    I have seen "compatibility" libraries. Maybe that was done due to earlier
    Linux work that was pure 64-bit.

    For this to work, the 64-bit kernel has to understand an ABI to get the
    32-bit pointers from the 32-bit process doing syscalls. Further, it has
    to be sure points it gives back are not only in 32 bits of space, but are
    valid in a 32-bit address space. Consider mmap(). It can choose what
    address to map space into, if not asked to use a specific address. For
    a 32-bit process, it has to know the limits of what it can choose during
    the kernel code carrying out these steps.


    | There is no such thing as '32-bit compatibility libraries'. The x86_64
    | processor can run as a ia32 (eg i686) processor and can run 32-bit
    | programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
    | processor bit (or whatever) to put it into the proper 'mode'.

    There's more to this than just processor mode. There's an ABI for the
    syscalls. 32-bit libraries don't just make 64 bits of space to pass the
    pointers to the kernel with. So the kernel has to be able to handle
    both ABIs if it can handle true pure-32-bit processes.


    |> The question might need to be extended in the case of virtualization such as
    |> Xen. But until someone grasps the conceptual difference between running a
    |> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
    |> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    | THERE IS NO SUCH THING!!! GET THIS OUT
    | OUT OF YOUR MIND!!!!!!!!!!!

    Sorry, but memory just doesn't erase like that. I have seen it, so I know
    it does exist. Maybe it's all moot today.


    | The virtualization systems (eg Xen) handle all of this. I am sure that
    | if you install a 64-bit virtualization system on a 64-bit system and
    | have it provide a batch of virtual 32-bit systems, it will work just
    | fine -- each of the virtual 32-bit systems will have a 32-bit kernel.
    |
    | You can *probably* install and run a 32-bit version of the
    | virtualization system (eg Xen), but why would you do this on a 64-bit
    | system with a 64-bit kernel?
    |
    | What *exactly* are you trying to achieve here?

    I'm trying to get to the full truth.

    There are a lot of issues when dealing with a mix of 32-bit and 64-bit.
    A 64-bit kernel that can fully handle either pure 32-bit processes or
    pure 64-bit processes has to be able to deal with those issues, such as
    having both 32-bit and 64-bit ABIs. Maybe it's as simple as a .config
    setting to include or not include the 32-bit ABI (because maybe someone
    that does not intend to run anything at 32-bit wants to save the space
    and not include that).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  6. Re: 32 bit OS, 4 GB limit?

    At 15 Jul 2008 19:23:57 GMT phil-news-nospam@ipal.net wrote:

    >
    > In comp.os.linux.misc Robert Heller wrote:
    >
    > | No, they don't do that -- I don't think they can. There are no '32-bit
    > | compatibility libraries', they are just the 32-bit libraries. When a
    > | 32-bit program in running, that process is 'locked' in 32-bit
    > | processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
    > | level, at least in *user mode*. The 32-bit libraries are the *same*
    > | 32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
    > | installed 32-bit libraries from a 32-bit distro on a 64-bit system
    > | (running a 64-bit kernel) [I had an old 32-bit program that used old
    > | shared libraries and it was too much trouble to mess with re-building it
    > | on the 64-bit box]. The 32-bit libraries use the 32-bit
    > | library-calling-ABI, just like on a 32-bit i[3456]86 system. The
    > | *kernel* runs in 64-bit mode and has access to the 64-bit address
    > | space, in *kernel* mode.
    >
    > I have seen "compatibility" libraries. Maybe that was done due to earlier
    > Linux work that was pure 64-bit.


    The only 'compatibility' libraries I've seen are ones that provide
    compatibility to older systems (eg libc5 compatibility libraries or
    compatibility libraries for other older libraries). I have *never* seen
    32/64 bit compatibility libraries *ever*. You are confusing something
    else. Maybe MS-Windows plays this sort of games?

    Note: I might have seen compatibility libraries on 32/64 bit Irix (MIPS
    processor) or Solaris (32/64 bit Sparc), but never on x86 64-bit Linux.

    >
    > For this to work, the 64-bit kernel has to understand an ABI to get the
    > 32-bit pointers from the 32-bit process doing syscalls. Further, it has
    > to be sure points it gives back are not only in 32 bits of space, but are
    > valid in a 32-bit address space. Consider mmap(). It can choose what
    > address to map space into, if not asked to use a specific address. For
    > a 32-bit process, it has to know the limits of what it can choose during
    > the kernel code carrying out these steps.


    The kernel ABI is the same for both 32 and 64 bit kernels. The kernel
    *knows* if the calling process was 32-bit or 64-bit (there is status info in a
    status register telling it this).

    >
    >
    > | There is no such thing as '32-bit compatibility libraries'. The x86_64
    > | processor can run as a ia32 (eg i686) processor and can run 32-bit
    > | programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
    > | processor bit (or whatever) to put it into the proper 'mode'.
    >
    > There's more to this than just processor mode. There's an ABI for the
    > syscalls. 32-bit libraries don't just make 64 bits of space to pass the
    > pointers to the kernel with. So the kernel has to be able to handle
    > both ABIs if it can handle true pure-32-bit processes.


    The 32-bit libraries use the same syscalls on a 64-bit machine with a
    64-bit kernel as they do on a 32-bit machine with a 32-bit kernel. They
    pass 32-bit pointers and get 32-bit addresses back.

    >
    >
    > |> The question might need to be extended in the case of virtualization such as
    > |> Xen. But until someone grasps the conceptual difference between running a
    > |> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
    > |> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
    > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > | THERE IS NO SUCH THING!!! GET THIS OUT
    > | OUT OF YOUR MIND!!!!!!!!!!!
    >
    > Sorry, but memory just doesn't erase like that. I have seen it, so I know
    > it does exist. Maybe it's all moot today.


    I would thing so.

    >
    >
    > | The virtualization systems (eg Xen) handle all of this. I am sure that
    > | if you install a 64-bit virtualization system on a 64-bit system and
    > | have it provide a batch of virtual 32-bit systems, it will work just
    > | fine -- each of the virtual 32-bit systems will have a 32-bit kernel.
    > |
    > | You can *probably* install and run a 32-bit version of the
    > | virtualization system (eg Xen), but why would you do this on a 64-bit
    > | system with a 64-bit kernel?
    > |
    > | What *exactly* are you trying to achieve here?
    >
    > I'm trying to get to the full truth.
    >
    > There are a lot of issues when dealing with a mix of 32-bit and 64-bit.
    > A 64-bit kernel that can fully handle either pure 32-bit processes or
    > pure 64-bit processes has to be able to deal with those issues, such as
    > having both 32-bit and 64-bit ABIs. Maybe it's as simple as a .config
    > setting to include or not include the 32-bit ABI (because maybe someone
    > that does not intend to run anything at 32-bit wants to save the space
    > and not include that).


    I'm going to check on a 64bit machine, but I don't think it works that
    way. You can *always* grab the kernel sources and look for yourself.
    To misquote Ben: "Use the Source, Phil"

    The kernel config for the 64bit machine starts with:

    CONFIG_X86_64=y
    CONFIG_64BIT=y
    CONFIG_X86=y

    Unless the 'CONFIG_X86' corresponds to the 32-bit ABI (not sure if that
    even makes sense)


    >


    --
    Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
    Deepwoods Software -- Linux Installation and Administration
    http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
    heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk


  7. Canon Linux Was Re: 32 bit OS, 4 GB limit?

    Robert Heller wrote:
    > At 15 Jul 2008 19:23:57 GMT phil-news-nospam@ipal.net wrote:
    >
    >> In comp.os.linux.misc Robert Heller wrote:
    >>
    >> | No, they don't do that -- I don't think they can. There are no '32-bit
    >> | compatibility libraries', they are just the 32-bit libraries. When a
    >> | 32-bit program in running, that process is 'locked' in 32-bit
    >> | processing mode. Its shared libraries CANNOT do ANYTHING at a 64-bit
    >> | level, at least in *user mode*. The 32-bit libraries are the *same*
    >> | 32-bit libraries that ship with the 32-bit (eg i386) system. *I've*
    >> | installed 32-bit libraries from a 32-bit distro on a 64-bit system
    >> | (running a 64-bit kernel) [I had an old 32-bit program that used old
    >> | shared libraries and it was too much trouble to mess with re-building it
    >> | on the 64-bit box]. The 32-bit libraries use the 32-bit
    >> | library-calling-ABI, just like on a 32-bit i[3456]86 system. The
    >> | *kernel* runs in 64-bit mode and has access to the 64-bit address
    >> | space, in *kernel* mode.
    >>
    >> I have seen "compatibility" libraries. Maybe that was done due to earlier
    >> Linux work that was pure 64-bit.

    >
    > The only 'compatibility' libraries I've seen are ones that provide
    > compatibility to older systems (eg libc5 compatibility libraries or
    > compatibility libraries for other older libraries). I have *never* seen
    > 32/64 bit compatibility libraries *ever*. You are confusing something
    > else. Maybe MS-Windows plays this sort of games?
    >
    > Note: I might have seen compatibility libraries on 32/64 bit Irix (MIPS
    > processor) or Solaris (32/64 bit Sparc), but never on x86 64-bit Linux.
    >
    >> For this to work, the 64-bit kernel has to understand an ABI to get the
    >> 32-bit pointers from the 32-bit process doing syscalls. Further, it has
    >> to be sure points it gives back are not only in 32 bits of space, but are
    >> valid in a 32-bit address space. Consider mmap(). It can choose what
    >> address to map space into, if not asked to use a specific address. For
    >> a 32-bit process, it has to know the limits of what it can choose during
    >> the kernel code carrying out these steps.

    >
    > The kernel ABI is the same for both 32 and 64 bit kernels. The kernel
    > *knows* if the calling process was 32-bit or 64-bit (there is status info in a
    > status register telling it this).
    >
    >>
    >> | There is no such thing as '32-bit compatibility libraries'. The x86_64
    >> | processor can run as a ia32 (eg i686) processor and can run 32-bit
    >> | programs 'natively'. The kernel/dynamic loader tweaks the kernel-mode
    >> | processor bit (or whatever) to put it into the proper 'mode'.
    >>
    >> There's more to this than just processor mode. There's an ABI for the
    >> syscalls. 32-bit libraries don't just make 64 bits of space to pass the
    >> pointers to the kernel with. So the kernel has to be able to handle
    >> both ABIs if it can handle true pure-32-bit processes.

    >
    > The 32-bit libraries use the same syscalls on a 64-bit machine with a
    > 64-bit kernel as they do on a 32-bit machine with a 32-bit kernel. They
    > pass 32-bit pointers and get 32-bit addresses back.
    >
    >>
    >> |> The question might need to be extended in the case of virtualization such as
    >> |> Xen. But until someone grasps the conceptual difference between running a
    >> |> 32-bit executable with 32-bit libraries under a 32-bit kernel ... and ...
    >> |> running a 32-bit executable with 32-bit to 64-bit compatibility libraries
    >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> | THERE IS NO SUCH THING!!! GET THIS OUT
    >> | OUT OF YOUR MIND!!!!!!!!!!!
    >>
    >> Sorry, but memory just doesn't erase like that. I have seen it, so I know
    >> it does exist. Maybe it's all moot today.

    >
    > I would thing so.
    >
    >>
    >> | The virtualization systems (eg Xen) handle all of this. I am sure that
    >> | if you install a 64-bit virtualization system on a 64-bit system and
    >> | have it provide a batch of virtual 32-bit systems, it will work just
    >> | fine -- each of the virtual 32-bit systems will have a 32-bit kernel.
    >> |
    >> | You can *probably* install and run a 32-bit version of the
    >> | virtualization system (eg Xen), but why would you do this on a 64-bit
    >> | system with a 64-bit kernel?
    >> |
    >> | What *exactly* are you trying to achieve here?
    >>
    >> I'm trying to get to the full truth.
    >>
    >> There are a lot of issues when dealing with a mix of 32-bit and 64-bit.
    >> A 64-bit kernel that can fully handle either pure 32-bit processes or
    >> pure 64-bit processes has to be able to deal with those issues, such as
    >> having both 32-bit and 64-bit ABIs. Maybe it's as simple as a .config
    >> setting to include or not include the 32-bit ABI (because maybe someone
    >> that does not intend to run anything at 32-bit wants to save the space
    >> and not include that).

    >
    > I'm going to check on a 64bit machine, but I don't think it works that
    > way. You can *always* grab the kernel sources and look for yourself.
    > To misquote Ben: "Use the Source, Phil"
    >
    > The kernel config for the 64bit machine starts with:
    >
    > CONFIG_X86_64=y
    > CONFIG_64BIT=y
    > CONFIG_X86=y
    >
    > Unless the 'CONFIG_X86' corresponds to the 32-bit ABI (not sure if that
    > even makes sense)
    >
    >
    >


    If someone came up with cli search string to locate the compatibility
    library enabling i386 Canon-Linux files on a Hardy AMD64 OS I would have
    far more room on my computer desk
    ftp://download.canon.jp/pub/driver/bj/linux/

    (Posted the link because so many insisted there's no Canon cups for Linux)


    --
    Bob
    Calling alcoholism 'a disease' is
    the politically correct substitute for 'a self induced insanity.'

  8. Re: 32 bit OS, 4 GB limit?

    phil-news-nospam@ipal.net wrote:
    > There's nothing the PAE design that would prevent a 32-bit PAE system from
    > remapping the lost 0.75GB of RAM into a location above the 4GB address as
    > long as the system is not fully populated to the PAE limit of 64GB. However,
    > the real question is whether or not real implementations have been made to
    > do just that.




    There are a couple of things preventing that. If you map the 0.75GB up
    above the 4GB address space, then your applications won't be able to see
    it. Despite PAE, each individual app is still limited to 4GB of address
    space. Multiple applications can exist in different 4GB spaces, but as
    far as they are concerned they occupy the space from 0-4GB in the
    address range. So mapping the missing 0.75GB to the range from 4GB upto
    4.75GB will result in the application not seeing that memory. Also if
    you do manage to map the memory below the 4GB limit, then the reserved
    hardware addresses will no longer function.

    Yousuf Khan

  9. Re: 32 bit OS, 4 GB limit?

    Yousuf Khan wrote:
    > phil-news-nospam@ipal.net wrote:
    >> There's nothing the PAE design that would prevent a 32-bit PAE system
    >> from
    >> remapping the lost 0.75GB of RAM into a location above the 4GB address as
    >> long as the system is not fully populated to the PAE limit of 64GB.
    >> However,
    >> the real question is whether or not real implementations have been
    >> made to
    >> do just that.

    >
    >
    >
    > There are a couple of things preventing that. If you map the 0.75GB up
    > above the 4GB address space, then your applications won't be able to see
    > it. Despite PAE, each individual app is still limited to 4GB of address
    > space. Multiple applications can exist in different 4GB spaces, but as
    > far as they are concerned they occupy the space from 0-4GB in the
    > address range. So mapping the missing 0.75GB to the range from 4GB upto
    > 4.75GB will result in the application not seeing that memory. Also if
    > you do manage to map the memory below the 4GB limit, then the reserved
    > hardware addresses will no longer function.
    >
    > Yousuf Khan


    For the foreseeable future, I don't see how many desktop users would
    want to exceed the 4GB/process limit in PAE. Servers, maybe, and they
    should have 64bit processors except for the low-end ones which can get
    away with using 32 bit processors.

    The only applications which would really need more than 4GB for a
    process on the desktop market in the next couple of years are probably
    games and 3D design, etc., but for a simple office machine, 32 bit will
    suffice for a few years yet.

  10. Re: 32 bit OS, 4 GB limit?

    On Wed, 16 Jul 2008 13:38:11 -0400, Yousuf Khan wrote:

    > phil-news-nospam@ipal.net wrote:
    >> There's nothing the PAE design that would prevent a 32-bit PAE system
    >> from remapping the lost 0.75GB of RAM into a location above the 4GB
    >> address as long as the system is not fully populated to the PAE limit
    >> of 64GB. However, the real question is whether or not real
    >> implementations have been made to do just that.

    >
    >
    >
    > There are a couple of things preventing that. If you map the 0.75GB up
    > above the 4GB address space, then your applications won't be able to see
    > it. Despite PAE, each individual app is still limited to 4GB of address
    > space. Multiple applications can exist in different 4GB spaces, but as
    > far as they are concerned they occupy the space from 0-4GB in the
    > address range. So mapping the missing 0.75GB to the range from 4GB upto
    > 4.75GB will result in the application not seeing that memory. Also if
    > you do manage to map the memory below the 4GB limit, then the reserved
    > hardware addresses will no longer function.
    >
    > Yousuf Khan


    You are confusing physical and logical addresses. The physical space with
    PAE is 64G, the logical space that a process sees is 4G. The MMU maps
    each page of virtual memory to a page of physical memory by translating
    the 32 bit virtual address into a 36 physical address. The 36 bit
    physical address can point to any page in the 64G space so you can map
    the RAM and IO space anywhere you want within the 64G space.

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3