57

This question is motivated by my shock when I discovered that Mac OS X kernel uses 750MB of RAM.

I have been using Linux for 20 years, and I always "knew" that the kernel RAM usage is dwarfed by X (is it true? has it ever been true?).

So, after some googling, I tried slabtop which told me:

Active / Total Size (% used)       : 68112.73K / 72009.73K (94.6%)

Does this mean that my kernel is using ~72MB of RAM now?

(Given that top reports Xorg's RSS as 17M, the kernel now dwarfs X, not the other way around).

What is the "normal" kernel RAM usage (range) for a laptop?

Why does MacOS use an order of magnitude more RAM than Linux?

PS. No answer here addressed the last question, so please see related questions:

sds
  • 1,686

3 Answers3

50

Kernel is a bit of a misnomer. The Linux kernel is comprised of several proceses/threads + the modules (lsmod) so to get a complete picture you'd need to look at the whole ball and not just a single component.

Incidentally mine shows slabtop:

 Active / Total Size (% used)       : 173428.30K / 204497.61K (84.8%)

The man page for slabtop also had this to say:

The slabtop statistic header is tracking how many bytes of slabs are being used and it not a measure of physical memory. The 'Slab' field in the /proc/meminfo file is tracking information about used slab physical memory.

Dropping caches

Dropping my caches as @derobert suggested in the comments under your question does the following for me:

$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
$

 Active / Total Size (% used)       : 61858.78K / 90524.77K (68.3%)

Sending a 3 does the following: free pagecache, dentries and inodes. I discuss this more in this U&L Q&A titled: Are there any ways or tools to dump the memory cache and buffer?". So 110MB of my space was being used by just maintaining the info regarding pagecache, dentries and inodes.

Additional Information

So how much RAM is my Kernel using?

This picture is a bit foggier to me, but here are the things that I "think" we know.

Slab

We can get a snapshot of the Slab usage using this technique. Essentially we can pull this information out of /proc/meminfo.

$ grep Slab /proc/meminfo
Slab:             100728 kB

Modules

Also we can get a size value for Kernel modules (unclear whether it's their size from on disk or when in RAM) by pulling these values from /proc/modules:

$ awk '{print $1 " " $2 }' /proc/modules | head -5
cpufreq_powersave 1154
tcp_lp 2111
aesni_intel 12131
cryptd 7111
aes_x86_64 7758

Slabinfo

Much of the details about the SLAB are accessible in this proc structure, /proc/slabinfo:

$ less /proc/slabinfo | head -5
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nf_conntrack_ffff8801f2b30000      0      0    320   25    2 : tunables    0    0    0 : slabdata      0      0      0
fuse_request         100    125    632   25    4 : tunables    0    0    0 : slabdata      5      5      0
fuse_inode            21     21    768   21    4 : tunables    0    0    0 : slabdata      1      1      0

Dmesg

When your system boots there is a line that reports memory usage of the Linux kernel just after it's loaded.

$ dmesg |grep Memory:
[    0.000000] Memory: 7970012k/9371648k available (4557k kernel code, 1192276k absent, 209360k reserved, 7251k data, 948k init)

References

zypA13510
  • 105
slm
  • 369,824
  • 1
    Is there anyway to get the complete picture ? – Gilles Oct 23 '13 at 19:09
  • @Gilles - of how much memories in use, right? I seem to remember a Q regarding that before, you? – slm Oct 23 '13 at 19:10
  • @Gilles - I think this is close to what you're asking about: grep Slab /proc/meminfo. – slm Oct 23 '13 at 19:17
  • @Gilles - there is also this: /proc/slabinfo, which looks to be the source for slabtop, so one could calculate the amounts from here for a more accurate total count. – slm Oct 23 '13 at 19:23
  • @Gilles - also this, awk '{print $1 " " $2 }' /proc/modules which are the sizes of the modules. Not sure if they are their sizes from on disk or when in RAM. – slm Oct 23 '13 at 19:28
  • @Gilles - I've pulled some of the pieces together at the bottom of this A. But I still feel like I'm dancing around the central question of what's the total being used NOW. I have several of the pieces but don't see how they all fit together. – slm Oct 23 '13 at 19:49
  • I'm not the one from the previous question you where referring to. Thanks for your updates and comments, I have what I need. – Gilles Oct 23 '13 at 20:17
  • @Gilles - you were asking about the complete picture weren't you? – slm Oct 23 '13 at 21:16
  • 2
    column 2 of /proc/modules is more likely to be loaded module size in memory as on-disk modules are normally compressed (e.g. on Fedora 27 it's xz), I've checked tg3 NIC driver, the on disk size (either compressed or original file size) does not match the byte size showing up in /proc/modules. – Terry Wang Dec 12 '17 at 01:00
  • The column 2 of /proc/modules is the same size that you can see in lsmod output. It is the size used by module in memory. See this answer for explanation. – Hi-Angel Apr 11 '20 at 16:51
8

How about this:

Active / Total Size (% used)       : 4709.24K / 5062.03K

That's on a freshly booted, very small machine running headless with a normal kernel. So it doesn't require much.

As derobert hints, the kernel will make use of available memory for caching and that's a lot of what you see in slabtop. In addition to the file cache, this has to do with sharable memory from userspace processes that is no longer in use. The kernel leaves it there until either the same stuff is required again, or else something actively needs RAM, in which case it gets forgotten. An analogy would be taking a book off a shelf and laying it open to read on a table: when you are done reading, you can leave the book open on the table in case you need to look at it again.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
5

On this 512 GB RAM server running Solaris, the kernel uses 25 GB:

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                    3210102             25078    5%
Anon                     15266226            119267   23%
Exec and libs               41457               323    0%
Page cache                3539331             27651    5%
Free (cachelist)         13799571            107809   21%
Free (freelist)          30093164            235102   46%

Total                    65949851            515233
Physical                 65927406            515057

That smaller one has more than half of its RAM used by the kernel:

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                    2149699             16794   52%
Anon                       517016              4039   13%
Exec and libs               15420               120    0%
Page cache                  21840               170    1%
Free (cachelist)             8768                68    0%
Free (freelist)           1404862             10975   34%

Total                     4117605             32168
Physical                  4096002             32000

Nothing to worry about, unused RAM is wasted RAM anyway.

jlliagre
  • 61,204
  • 3
    Please describe how you did achieve your output. – Maus Aug 19 '15 at 14:57
  • @Maus by running echo ::memstat | mdb -k on some Solaris 10 production servers that predate update 10/09. – jlliagre Aug 19 '15 at 15:09
  • 1
    "unused RAM is wasted RAM anyway." Not always true, unused RAM is used as cache. This is the yellow colored section in htop or the "Cache" section of GNOME System Monitor. – Aaron Franke Jun 02 '20 at 03:12
  • 2
    @AaronFranke When I write unused, I mean unused. RAM used as cache can be reported as free RAM (because it is immediately available should there is demand for it) but is nevertheless definitely used. – jlliagre Jun 02 '20 at 08:01