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:

  • On my machine, it reports nearly 2GB... but when you look at the details, it's all related to the filesystem cache.
    – derobert
    Commented Oct 23, 2013 at 15:03
  • 2
    Indeed, if I do a echo 3 > /proc/sys/vm/drop_caches, then I only have 80MB used.
    – derobert
    Commented Oct 23, 2013 at 15:12
  • According to comments in the link you provide, memory used by integrated graphics hardware is included in the kernel_task accounting. Commented Oct 23, 2013 at 23:46

3 Answers 3


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.


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


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


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


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)


  • 1
    Is there anyway to get the complete picture ?
    – Gilles
    Commented Oct 23, 2013 at 19:09
  • @Gilles - of how much memories in use, right? I seem to remember a Q regarding that before, you?
    – slm
    Commented Oct 23, 2013 at 19:10
  • @Gilles - I think this is close to what you're asking about: grep Slab /proc/meminfo.
    – slm
    Commented Oct 23, 2013 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
    Commented Oct 23, 2013 at 19:23
  • 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
    Commented Dec 12, 2017 at 1:00

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.


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.

  • 3
    Please describe how you did achieve your output.
    – Maus
    Commented Aug 19, 2015 at 14:57
  • @Maus by running echo ::memstat | mdb -k on some Solaris 10 production servers that predate update 10/09.
    – jlliagre
    Commented Aug 19, 2015 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. Commented Jun 2, 2020 at 3: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
    Commented Jun 2, 2020 at 8:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .