CODEWITHSUNDEEP
linuxmemory-managementlinux-kernel
A. Sarid
A. Sarid

Reputation: 3996

Linux memory allocation - order changed by 1

I will try to describe the issue as much as I can. Though, I won't be able to post all the relevant code.

The case is as follow, I made few changes in the code, all of them were in user-space. I didn't change anything in the kernel code.
After compiling and working for a while with this release I suddenly noticed that the Ephemeral ports range has been changed.
After investigating I encountered that this was caused because of a change in the order of magnitude (in memory allocation). But as I said before, no-one touched this code.

Here is some of the log messages of the linux bootup from before and after this change. You can notice that change in the order I mentioned before.

After the change: 

[000000.000] Determined physical RAM map:
[000000.000]  memory: 0000000007000000 @ 0000000000c10000 (usable)
[000000.015] reserve bootmem for memoops 0000000000020000 @ 0000000007bf0000
[000000.019] Primary instruction cache 32kB, virtually tagged, 4 way, 64 sets, linesize 128 bytes.
[000000.019] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
[000000.020] PID hash table entries: 512 (order: 9, 16384 bytes)
[000000.020] Using 500.000 MHz high precision timer.
[000000.227] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
[000000.240] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
[000000.266] Memory: 112408k/114688k available (2062k kernel code, 2136k reserved, 533k data, 200k init, 0k highmem)

Before the change:

[000000.000] Determined physical RAM map:
[000000.000]  memory: 0000000007400000 @ 0000000000c00000 (usable)
[000000.016] reserve bootmem for memoops 0000000000020000 @ 0000000007fe0000
[000000.020] Primary instruction cache 32kB, virtually tagged, 4 way, 64 sets, linesize 128 bytes.
[000000.020] Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes.
[000000.020] PID hash table entries: 1024 (order: 10, 32768 bytes)
[000000.228] Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
[000000.242] Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
[000000.269] Memory: 116280k/118784k available (2062k kernel code, 2344k reserved, 533k data, 200k init, 0k highmem)

Note: I already tried to take off my changes and recompile, but the issue is still there for some reason.

Maybe someone know what might affect this? How can this happen?

Upvotes: 0

Views: 140

Answers (1)

smilingjames
smilingjames

Reputation: 101

The application codes will not bring any influence to kernel's booting, because it begin to run after kernel booting.

This issue should be caused by your physical memory change, you can verified via kernel source codes:

mm/page_alloc.c
/* round applicable memory size up to nearest megabyte */
            numentries = nr_kernel_pages;
            numentries += (1UL << (20 - PAGE_SHIFT)) - 1;
            numentries >>= 20 - PAGE_SHIFT;
            numentries <<= 20 - PAGE_SHIFT;
....
log2qty = ilog2(numentries);
....
printk(KERN_INFO "%s hash table entries: %ld (order: %d, %lu bytes)\n",
           tablename,
           (1UL << log2qty),
           ilog2(size) - PAGE_SHIFT,
           size);

If the boot parameter keep the same, you can check:

  • if hardware keep the same
  • did you boot via different method, such as change from legacy to UEFI mode
  • if you have multi target with the same config(mem size, cpu, chipset etc.), you can verified on another board to avoid the hardware problem on this board.

Upvotes: 1

Related Questions