my question may be silly. But even after some searching, I still didn't get why highmem is unnecessary in 64bit architectures. As far as I searched, in x64bit, there is no highmem. In other words, all the physical memory is directly mapped with virtual memory. But at the same time, all the processes will have their own address space starting from 0x00000 to sth for various reasons including security. If all the physical memory is already directly mapped with each piece of virtual memory, How can we create a separate and isolated address space for each process without changing mapping between physical memory and virtual memory?

When memory is allocated via **kmalloc** (i.e., slab cache allocation like slab_alloc_node), it returns a virtual memory address. Presumably, when accessing this virtual address, the corresponding PTE (which translates the virtual address to a physical address) already exists, enabling address translation because kernel address don't allow page fault. Who creates this PTE, and when is it created? I am using a 64-bit system, not a 32-bit one. In 32-bit systems, I understand that there is a “low memory” region (typically within 1GiB), and that this low memory is pre-mapped to physical memory during boot. However, I’m curious about how this works on 64-bit systems. According to this StackOverflow post (https://stackoverflow.com/questions/30541036/will-physical-addresses-of-all-paging-structures-in-linux-be-mapped-in-the-page) , it says that on 64-bit systems, > “all physical addresses are always mapped with a Supervisor mapping in > the kernel half of the address space.” , And here (https://unix.stackexchange.com/questions/527430/which-processes-page-table-does-vmalloc-allocate-new-memory-in) said > the page table entries for kmalloc have already been allocated. I want to verify whether this is actually true. Here’s why I’m skeptical: suppose my machine has 128GiB of DRAM, and each PTE is 8 bytes. Then, just the page table itself would require 256MiB (128GiB/4KiB * 8Byte). But when I run numastat -m after boot, the size of the PageTable doesn’t appear to be that large. So I wonder what’s really going on.

I have gone through Robert Love's Linux Kernel Development, and other sources. And everywhere it mentions that on a 32 bit x86 system the kernel owns the top 1 GB of the virtual address space, out of that upto 896 MB is mapped contiguously onto physical memory (called ZONE_NORMAL) the rest is mapped into the remaining 128 MB space as required, and may not be contiguous (ZONE_HIGHMEM). On 64 bit, the problem of not having enough virtual address space is eliminated. And the memory map is described as,

0xffffffffffffffff  +-----------+
                    |           |
                    |           | Kernelspace
                    |           |
0xffff800000000000  +-----------+
                    |           |
                    |           |
                    |   hole    |
                    |           |
                    |           |
0x00007fffffffffff  +-----------+
                    |           |
                    |           |  Userspace
                    |           |
0x0000000000000000  +———————————+

However, it is not clear, in this map how much of the kernelspace is required to be physically contiguous (as defined in ZONE_NORMAL). and how much is mapped as required. Is the ZONE_HIGHMEM in 64 bit kernel always 0? Since all memory is quite within range of the virtual address space? But the kernel's fixed contiguous memory (which is un-pageable) would also require to be small, since that chunk of physical memory would never be available to other user processes. So the kernel would require to use memory which need not be contiguous (like ZONE_HIGHMEM), as required. This conflicts with the ZONE_HIGHMEM being empty on 64-bit kernels. So I am confused about how much of the kernelspace is fixed physically contiguous and how much is non-contiguous in case of 64 bit kernels.

I came upon this question : https://unix.stackexchange.com/questions/472223/whats-the-use-of-having-a-kernel-part-in-the-virtual-memory-space-of-linux-proc and based on the answer and the comments on the answer : >the kernel memory map includes a direct mapping of all physical memory, so everything in memory appears there; it also includes separate mappings for the kernel, modules etc., so the physical addresses containing the kernel appear in at least two different mappings Is this true? I couldn't find any source or reference for this, and why would it include a map of the entire physical memory and then again have a separate mapping of kernel modules? Isn't that redundant? Can someone explain in a simple manner what is inside the kernel part of virtual memory of processes in 64-bit Linux? and **please provide a source for the answer**! because I couldn't find anything related to this in any book or paper.

At this writing (November 2024) are there still any currently-maintained 64-bit Linux distributions that install and run successfully on x86_64-v1 micro-architecture level hardware? Or do all currently maintained 64-bit distributions require a CPU supporting at minimum the x86_64-v2 instruction set?

Although the Android Development Tools (ADT) bundle is available as a zip package for 'Linux 64 Bit' it states following requirements : > 64-bit distributions must be capable of running 32-bit applications. And indeed, just running the packaged eclipse on a Fedora 17 64 bit system results in errors, because it can't 'find' several development tools, e.g. adb or aapt: > Error executing aapt: Cannot run program "/home/juser/local/adt-bundle-linux/sdk/platform-tools/aapt": error=2, No such file or directory: error=2, No such file or directory The 'no such file' is misleading because it is there (under $HOME/local): adt-bundle-linux/sdk/platform-tools/aapt But I can't execute it on the shell: ~/local $ ./adt-bundle-linux/sdk/platform-tools/aapt zsh: no such file or directory: ./adt-bundle-linux/sdk/platform-tools/aapt Looking at the file $ file adt-bundle-linux/sdk/platform-tools/aapt adt-bundle-linux/sdk/platform-tools/aapt: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped we see that it is a 32 binary. And it seems that my system (currently) is not capable of running 32-bit applications. How do I change that? How do I make a current Fedora 64 bit system capable of running 32 bit applications? (Of course one could also ask why someone ends up putting 32 bit binaries into a binary package called 'Linux 64 bit' ...)

I can run steam games through the application itself and certain games successfully launch and play like Doki Doki Literature club. However games like Destiny or Poe fail to run and I am met with the response createDXGIFactory1: call failed. So I did some research and games like that require a 32 bit driver, while I have only the 64 bit driver, I've attempted to download the NVIDIA driver and my terminal presents the following message: (1) Another program may be editing the same file. If this is the case, be careful not to end up with two different instances of the same file when making changes. Quit, or continue with caution. (2) An edit session for this file crashed. If this is the case, use ":recover" or "vim -r /home/divinadivine/Downloads/NVIDIA-Linux-x86-384.111.run" to recover the changes (see ":help recovery"). If you did this already, delete the swap file "/home/divinadivin e/.cache/vim/swap/%home%divinadivine%Downloads%NVIDIA-Linux-x86-384. 111.run.swp" to avoid this message. Swap file "~/.cache/vim/swap/%home%divinadivine%Downloads%NVIDIA-Lin ux-x86-384.111.run.swp" already exists!

On my journey to create a 16 EiB sized file, I encountered the following issue: POSIX defines files to have their size represented using type off_t, and that "**blkcnt_t** and **off_t** shall be signed integer types." According to unistd.h , _POSIX_V7_LP64_OFF64 requires 64-bit off_t types, while _POSIX_V7_LPBIG_OFFBIG allows for larger ones: >_POSIX_V7_LP64_OFF64

The implementation provides a C-language compilation environment with 32-bit **int** and 64-bit **long**, **pointer**, and **off_t** types.

_POSIX_V7_LPBIG_OFFBIG

The implementation provides a C-language compilation environment with an **int** type using at least 32 bits and **long**, **pointer**, and **off_t** types using at least 64 bits.

The only reason for off_t being signed is its use in lseek and fseek , where the formal argument offset can be used to specify the file offset relative to some other value, if whence is set to either SEEK_CUR or SEEK_END. To me, this seems odd, as I can't imagine this case to be worth wasting half of the usable range for the file size, since any code relying on this feature could easily be rewritten to request the current absolute offset, add/subtract the relative offset and then seek to this calculated value. Are there any other reasons for POSIX to specify off_t to be a signed type? ## UPDATE I noticed that the UNIX PROGRAMMER’S MANUAL (TYPES ( 5 ), Seventh Edition, Volume 1 January, 1979) defined off_t to be a long: > typedef long off_t; Though, when digging further, I found FSEEK ( 3S ) to reveal it being used as signed long as well:

fseek(stream, offset, ptrname)
FILE *stream;
long offset;

> Fseek sets the position of the next input or output operation on the stream. The new position is at the signed distance offset bytes from the beginning, the current position, or the end of the file, according as ptrname has the value 0, 1, or 2.

Just made my Live-USB from 64bit Mint 21.3 (https://www.linuxmint.com/torrents/linuxmint-21.3-xfce-64bit.iso.torrent) and plugged into my old 32bit laptop, forgetting it still is such old. (Probably it's not relevant, but in any case: I created the USB stick basically following the answer at https://askubuntu.com/a/1227225/602021) Everything boots and runs fine, new software comes from amd64 repository, is installable and runs also. How can that be, given that it is software for another architecture? **EDIT:** Laptop chipset & model: $ lscpu Architecture: i686 CPU op-mode(s): 32-bit, 64-bit Address sizes: 36 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Vendor ID: GenuineIntel Model name: Intel(R) Core(TM)2 CPU T6600 @ 2.20GHz CPU family: 6 Model: 23 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 Stepping: 10 CPU(s) scaling MHz: 66% CPU max MHz: 2200,0000 CPU min MHz: 1200,0000 BogoMIPS: 4388,93 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe nx lm constant_tsc arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl est $ sudo dmidecode | grep -A3 '^System Information' System Information Manufacturer: Acer Product Name: Extensa 5220 Version: 0100

I have a 64-bit (amd64 a.k.a. x86_64) Debian or Ubuntu installation. I need to run 32-bit (i386/i686) programs occasionally, or to compile programs for a 32-bit system. How can I do this with a minimum of fuss? Bonus: what if I want to run or test with an older or newer release of the distribution?

I am working on an embedded Linux system (kernel-5.10.24), which is a **32bit** system, and it is using GLibc-2.38 to fix Y2k38. The rootfs is built from buildroot rel.2023-aug with Y2k38 fix. (built with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE). There are getty and login built from busybox-1.36.1 in the buildroot. Now I found strange things when I tried to read the /var/run/utmp with following codes (also built with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE).

#include 
#include 
#include 
#include 

int main() {
    FILE *fp;
    struct utmp ut;

    printf("XXXXXXXXX sizeof utmp: %ld\n", sizeof(ut));
    fp = fopen("/var/run/utmp", "r");
    if (fp == NULL) {
        perror("Error opening UTMP file");
        return 1;
    }

    while (fread(&ut, sizeof(struct utmp), 1, fp) == 1) {
        if (ut.ut_type == USER_PROCESS) {
            printf("Login Name: %s\n", ut.ut_user);
            printf("Login Time: %s", ctime(&ut.ut_tv.tv_sec));
        }
    }

    fclose(fp);

    return 0;
}

When root is logged in and run the code, it showed,

# /tmp/utmpread
XXXXXXXXX sizeof utmp: 400

But the size of /var/run/utmp is 384.

# stat /var/run/utmp
  File: /var/run/utmp
  Size: 384             Blocks: 8          IO Block: 4096   regular file
Device: fh/15d  Inode: 8           Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1970-01-01 01:14:24.270002128 +0000
Modify: 1970-01-01 00:03:12.000000000 +0000
Change: 1970-01-01 01:12:47.210002082 +0000

So based on my tests, it seemed that struct utmp is already built as 64bit of timeval_t, and the login and getty also report its size is 400Bytes. But the size of /var/run/utmp is still 384 Bytes, which is using 32bit timeval_t. I don't know why there is the mismatch (the code reports size of struct utmp is 400, but the file generated from struct utmp is 384), is it from the GLIBC or from the busybox? Thanks,

I have noticed, that Manjaro Linux (kernel 6.6.8) loads 32 bit executable files with ADDR_LIMIT_3GB set. Or as: setarch -B --3g. But I have a clear memory, that earlier it was not the case and 32 bit programs started in --4G mode. Is it hardcoded in the kernel or is configurable behavior? How to change it?

I have written a freeware console app in VB.net, which I have fine-tuned and successfully tested in headless Raspberry Pi Bullseye. I have also written a installation script after checking its dependencies (https://bit.ly/multilarm-linux) . However, on a fresh emulation (Raspberry Pi Bookworm emulation on VirtualBox), despite installing the dependencies (which to be fair, does not install new packages apart from Bass drivers), ldd outputs as follows: admin@raspberry:~ $ ldd ./Multilarm linux-vdso.so.1 (0x00007fff501f5000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8fa34d1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8fa34cb000) libz.so.1 => not found librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8fa34c1000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8fa34a7000) libstdc++.so.6 => not found libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8fa3361000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8fa318d000) /lib64/ld-linux-x86-64.so.2 (0x00007f8fa3f87000) I have tried installing lib64z1 and lib32stdc++6 with no avail. My app already contains the .net framework files as a single package. I am wondering whether this problem has to do anything with the fact that the RPi kernel is 64-bit (uname -m x86_64) running in a 32 bit namespace. admin@raspberry:~ $ locate libz.so.1 /usr/lib/i386-linux-gnu/libz.so.1 /usr/lib/i386-linux-gnu/libz.so.1.2.11 admin@raspberry:~ $ locate libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.28 /usr/lib32/libstdc++.so.6 /usr/lib32/libstdc++.so.6.0.28 /usr/share/gdb/auto-load/usr/lib/i386-linux-gnu/libstdc++.so.6.0.28-gdb.py /usr/share/gdb/auto-load/usr/lib32/libstdc++.so.6.0.28-gdb.py Please help.

I need to set the arch option in debootstrap. So I did some research and read the manual. After reading the manual I see that the section on the options simply says --arch=ARCH Implying that I should know the correct syntax for the architecture I need. I don't. I need 64 bit architecture. I know that "i386" can be used for 32bit architecture. What should I set the --arch option to if I want 64 bit architecture? Or more generally what would the range of options be? I could guess (but don't know and can't determine) that potentially the range or arch options depends on the OS being booted. In my case its a version of ubuntu that I know should work in 64bit. So the question becomes how would I determine the 64bit architecture option syntax? I could further guess (but again don't know and can't determine) that the option syntaxes are actually supplied by the booted OS and if I knew where to look I could figure it out. In which case, where would I look?

I am trying to understand the output of the free command on an AWS Linux server. For example, free -h gives: total used free shared buff/cache available Mem: 15G 2.2G 4.0G 16M 9.0G 12G Swap: 0B 0B 0B Whereas free -hl gives: total used free shared buff/cache available Mem: 15G 2.2G 4.0G 16M 9.0G 12G Low: 15G 11G 4.0G High: 0B 0B 0B Swap: 0B 0B 0B How can the "Low" used memory (11G) exceed the total used memory (2.2G)? From everything I'm reading, -l is supposed to split the totals into totals for "low" and "high" memory, which isn't even a distinction that's supposed to exist on 64-bit systems. What does the 11G actually mean then?

My AIX machine is currently running on 6.1 OS. I would like to know whether it is on PPC OR PPC64, Is there any command other than arch which gives the information about PPC ?

The documentation of the Linux kernel describes the virtual memory map . It says: > fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping What is this "cpu entry area"? Is it accessible in some way to code running in ring 3 (i.e. CPL3)?

I ask because I am experimenting with QEMU, and it seems that some CPL3 code that runs on the QEMU guest (Ubuntu server 18.04) attempts (I don't know whether it succeeds) to access memory in cpu_entry_area.
At first, I thought I did something wrong, as I thought that all addresses higher than 0x00007fffffffffff aren't accessible to CPL3, but then I found out about vsyscall (see here ). I tried to access vsyscall memory (specifically *(int *)0xffffffffff600000) from CPL3 code in the QEMU guest, and succeeded, but I got a segfault when I tried to access the cpu_entry_area (specifically *(int *)0xfffffe0000000ee0).

after looking at the sys monitor i saw that out of 8gigs i only had 3.3 available. both of the 4 gig sticks are perfectly fine, and the slots are perfectly fine, but it shows 2x4gigs in bios, and 2x4 in lshw. i literally do not understand OS: Linux mint 21.2 cinnamon. cinnamon ver: 5.8.4 lshw shows that i indeed have 2x4gigs of ram description: System Memory physical id: a slot: System board or motherboard size: 8GiB *-bank:0 description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: 8KTF51264AZ-1G6E1 vendor: Micron physical id: 0 serial: 11A01A3A slot: A1_DIMM0 size: 4GiB width: 64 bits clock: 1600MHz (0.6ns) *-bank:1 description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: 8KTF51264AZ-1G6E1 vendor: Micron physical id: 1 serial: 11A01A39 slot: A1_DIMM1 size: 4GiB width: 64 bits clock: 1600MHz (0.6ns) bios also shows 2x4gigs of ram BUT the system info shows i only have 3.3 and the sys gnome monitor shows that i only have 3.3 also, free -m output: total used free shared buff/cache available Mem: 3394 1122 887 24 1384 2016 Swap: 59558 0 59558 any information requested will be provided.

I'm planning to install a Debian 32-bit or 64-bit if possible. It is a Toshiba Netbook NB305-N410BL-bn The mfg specs list my Intel Atom® Processor N450 512K Cache, 1.66 GHz as a 64-bit processor https://ark.intel.com/content/www/us/en/ark/products/42503/intel-atom-processor-n450-512k-cache-1-66-ghz.html#tab-blade-1-0 The computer specs show it as a 32-bit running windows 7 starter. I don't know if this is the right distro, which installer, or if I should run 32 or 64-bit.

The boot chain here is UEFI -> 6.1.14 kernel built with EFI stub, initramfs loads and checks 5.4.109 kernel, then kexecs it. CPU is a 2-core Intel Atom N6210. When booted this way, at startup when the 5.4 kernel releases the second CPU, it immediately panics with an alignment exception. The same kernel image works fine when booted from EFI, or booted via kexec by the 5.4.109 kernel.