This entry is for those people who have ever wondered, "Why the hell is a simple KDE text editor taking up 25 megabytes of memory?" Many people are led to believe that many Linux applications, especially KDE or Gnome programs, are "bloated" based solely upon what tools like ps report. While this may or may not be true, depending on the program, it is not generally true -- many programs are much more memory efficient than they seem.
What ps reports
The ps tool can output various pieces of information about a process, such as its process id, current running state, and resource utilization. Two of the possible outputs are VSZ and RSS, which stand for "virtual set size" and "resident set size", which are commonly used by geeks around the world to see how much memory processes are taking up.
For example, here is the output of ps aux for KEdit on my computer:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
dbunker 3468 0.0 2.7 25400 14452 ? S 20:19 0:00 kdeinit: kedit
According to ps, KEdit has a virtual size of about 25 megabytes and a resident size of about 14 megabytes (both numbers above are reported in kilobytes). It seems that most people like to randomly choose to accept one number or the other as representing the real memory usage of a process. I'm not going to explain the difference between VSZ and RSS right now but, needless to say, this is the wrong approach; neither number is an accurate picture of what the memory cost of running KEdit is.
Why ps is "wrong"
Depending on how you look at it, ps is not reporting the real memory usage of processes. What it is really doing is showing how much real memory each process would take up if it were the only process running. Of course, a typical Linux machine has several dozen processes running at any given time, which means that the VSZ and RSS numbers reported by ps are almost definitely "wrong". In order to understand why, it is necessary to learn how Linux handles shared libraries in programs.
Most major programs on Linux use shared libraries to facilitate certain functionality. For example, a KDE text editing program will use several KDE shared libraries (to allow for interaction with other KDE components), several X libraries (to allow it to display images and copy and pasting), and several general system libraries (to allow it to perform basic operations). Many of these shared libraries, especially commonly used ones like libc, are used by many of the programs running on a Linux system. Due to this sharing, Linux is able to use a great trick: it will load a single copy of the shared libraries into memory and use that one copy for every program that references it.
For better or worse, many tools don't care very much about this very common trick; they simply report how much memory a process uses, regardless of whether that memory is shared with other processes as well. Two programs could therefore use a large shared library and yet have its size count towards both of their memory usage totals; the library is being double-counted, which can be very misleading if you don't know what is going on.
Unfortunately, a perfect representation of process memory usage isn't easy to obtain. Not only do you need to understand how the system really works, but you need to decide how you want to deal with some hard questions. Should a shared library that is only needed for one process be counted in that process's memory usage? If a shared library is used my multiple processes, should its memory usage be evenly distributed among the different processes, or just ignored? There isn't a hard and fast rule here; you might have different answers depending on the situation you're facing. It's easy to see why ps doesn't try harder to report "correct" memory usage totals, given the ambiguity.
Seeing a process's memory map
Enough talk; let's see what the situation is with that "huge" KEdit process. To see what KEdit's memory looks like, we'll use the pmap program (with the -d flag):
# pmap -d 489
Address Kbytes Mode Offset Device Mapping
08048000 40 r-x-- 0000000000000000 0fe:00000 kdeinit
08052000 4 rw--- 0000000000009000 0fe:00000 kdeinit
08053000 1164 rw--- 0000000008053000 000:00000 [ anon ]
40000000 84 r-x-- 0000000000000000 0fe:00000 ld-2.3.5.so
40015000 8 rw--- 0000000000014000 0fe:00000 ld-2.3.5.so
40017000 4 rw--- 0000000040017000 000:00000 [ anon ]
40018000 4 r-x-- 0000000000000000 0fe:00000 kedit.so
40019000 4 rw--- 0000000000000000 0fe:00000 kedit.so
40027000 252 r-x-- 0000000000000000 0fe:00000 libkparts.so.2.1.0
40066000 20 rw--- 000000000003e000 0fe:00000 libkparts.so.2.1.0
... (trimmed) ...
mapped: 25404K writeable/private: 2432K shared: 0K
I cut out a lot of the output; the rest is similar to what is shown. Even without the complete output, we can see some very interesting things. One important thing to note about the output is that each shared library is listed twice; once for its code segment and once for its data segment. The code segments have a mode of "r-x--", while the data is set to "rw---". The Kbytes, Mode, and Mapping columns are the only ones we will care about, as the rest are unimportant to the discussion.
If you go through the output, you will find that the lines with the largest Kbytes number are usually the code segments of the included shared libraries (the ones that start with "lib" are the shared libraries). What is great about that is that they are the ones that can be shared between processes. If you factor out all of the parts that are shared between processes, you end up with the "writeable/private" total, which is shown at the bottom of the output. This is what can be considered the incremental cost of this process, factoring out the shared libraries. Therefore, the cost to run this instance of KEdit (assuming that all of the shared libraries were already loaded) is around 2 megabytes. That is quite a different story from the 14 or 25 megabytes that ps reported.
What does it all mean?
The moral of this story is that process memory usage on Linux is a complex matter; you can't just run ps and know what is going on. This is especially true when you deal with programs that create a lot of identical children processes, like Apache. ps might report that each Apache process uses 10 megabytes of memory, when the reality might be that the marginal cost of each Apache process is 1 megabyte of memory. This information becomes critial when tuning Apache's MaxClients setting, which determines how many simultaneous requests your server can handle (although see one of my past postings for another way of increasing Apache's performance).
It also shows that it pays to stick with one desktop's software as much as possible. If you run KDE for your desktop, but mostly use Gnome applications, then you are paying a large price for a lot of redundant (but different) shared libraries. By sticking to just KDE or just Gnome apps as much as possible, you reduce your overall memory usage due to the reduced marginal memory cost of running new KDE or Gnome applications, which allows Linux to use more memory for other interesting things (like the file cache, which speeds up file accesses immensely).
Tuesday, January 5, 2010
Why doesn't free memory go down
Why Linux always seems to have so little free memory. Does this indicate some kind of problem in Linux or the application? No.
Someone at work asked (paraphrasing):
I have a process that uses a lot of memory while it's running, so the free memory (shown by free or top) goes right down to 60MB out of 8100MB.
But when the process exits, the free memory doesn't go back up. Why isn't memory released when the process exits?
The short answer is that you should never worry about the amount of free memory on Linux. The kernel attempts to keep this slightly above zero by keeping the cache as large as possible. This is a feature not a bug.
If you are concerned about VM performance then the most useful thing to watch is the page in/out rate, shown by the "bi" and "bo" columns in vmstat. Another useful measure (2.6 only) is the "wa" column, showing the amount of CPU time spent waiting for I/O. "wa" is probably the one you have to worry about most, because it shows CPU cycles that are essentially wasted because VM is too slow.
[root@sbandodk ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 201800 144024 974952 0 0 41 31 1098 896 14 3 83 1 0
As you said, linux is keeping the free memory into buffer cache, but when there is no process running how come the buffer cache is having 4GB and
how it is released 3GB to free memory.
Disk cache is maintained globally, not per-process. Files can remain in cache even after the process that was using them exited, because they might be used by another process. Freeing the cache would mean discarding cached data. There's no reason to do that until the data is obsolete (e.g. files are deleted) or the memory is needed for some other purpose.
After a while the free memory goes back up again.
Pages only become free when they're evicted to build up the free pool (see below), or when nothing useful can be stored in them. If there are gigabytes of free memory then the main cause is that the kernel doesn't have anything to cache in them.
This can happen when, for example, a file that was cached was deleted, or a filesystem is unmounted: there's no point keeping those pages cached because they can't be accessed. (Note that the kernel can still cache a file which is just unlinked, but still in use by applications.)
A similar case is that an application has allocated a lot of anonymous memory and then either exited or freed the memory. That data is discarded, so the pages are free.
Note that flushing the data to disk makes the pages clean, but not free. They can still be kept in memory in case they're read in the future. ("Clean" means the in-memory page is the same as the on-disk page.)
The guy in the second row asks:
So if Linux tries to keep the cache as large as possible, why is there 60MB free rather than zero?
Wouldn't it be better to cache an additional 60MB?
Linux keeps a little bit of memory free so that it is ready as soon as it needs to allocate more memory. If the extra 60MB was used for cache too then when a new allocation was required, the kernel would have to go through the cache and work out what to evict. Possibly it would need to wait for a page to be written out. This would make allocation slower and more complex. So there is a tradeoff where the page cache is made slightly slower so that allocation can be faster and simpler. The kernel keeps just a few free pages prepared in advance.
Someone at work asked (paraphrasing):
I have a process that uses a lot of memory while it's running, so the free memory (shown by free or top) goes right down to 60MB out of 8100MB.
But when the process exits, the free memory doesn't go back up. Why isn't memory released when the process exits?
The short answer is that you should never worry about the amount of free memory on Linux. The kernel attempts to keep this slightly above zero by keeping the cache as large as possible. This is a feature not a bug.
If you are concerned about VM performance then the most useful thing to watch is the page in/out rate, shown by the "bi" and "bo" columns in vmstat. Another useful measure (2.6 only) is the "wa" column, showing the amount of CPU time spent waiting for I/O. "wa" is probably the one you have to worry about most, because it shows CPU cycles that are essentially wasted because VM is too slow.
[root@sbandodk ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 201800 144024 974952 0 0 41 31 1098 896 14 3 83 1 0
As you said, linux is keeping the free memory into buffer cache, but when there is no process running how come the buffer cache is having 4GB and
how it is released 3GB to free memory.
Disk cache is maintained globally, not per-process. Files can remain in cache even after the process that was using them exited, because they might be used by another process. Freeing the cache would mean discarding cached data. There's no reason to do that until the data is obsolete (e.g. files are deleted) or the memory is needed for some other purpose.
After a while the free memory goes back up again.
Pages only become free when they're evicted to build up the free pool (see below), or when nothing useful can be stored in them. If there are gigabytes of free memory then the main cause is that the kernel doesn't have anything to cache in them.
This can happen when, for example, a file that was cached was deleted, or a filesystem is unmounted: there's no point keeping those pages cached because they can't be accessed. (Note that the kernel can still cache a file which is just unlinked, but still in use by applications.)
A similar case is that an application has allocated a lot of anonymous memory and then either exited or freed the memory. That data is discarded, so the pages are free.
Note that flushing the data to disk makes the pages clean, but not free. They can still be kept in memory in case they're read in the future. ("Clean" means the in-memory page is the same as the on-disk page.)
The guy in the second row asks:
So if Linux tries to keep the cache as large as possible, why is there 60MB free rather than zero?
Wouldn't it be better to cache an additional 60MB?
Linux keeps a little bit of memory free so that it is ready as soon as it needs to allocate more memory. If the extra 60MB was used for cache too then when a new allocation was required, the kernel would have to go through the cache and work out what to evict. Possibly it would need to wait for a page to be written out. This would make allocation slower and more complex. So there is a tradeoff where the page cache is made slightly slower so that allocation can be faster and simpler. The kernel keeps just a few free pages prepared in advance.
Thursday, December 31, 2009
Why does top output for cpu utilization differ from mpstat on smp systems
This can me reproduced by running the following commands:
# top
# mpstat
Notice, after you run the top command, press "1" to get a list of all cores. This will show the actual cup utilization for all the cores.
Example:
Top command run without pressing "1"
Cpu(s): 9.5%us, 12.0%sy, 0.0%ni, 77.9%id, 0.4%wa, 0.0%hi, 0.0%si, 0.2%st
Top command run after pressing "1"
Cpu0 : 2.0%us, 8.0%sy, 0.0%ni, 77.1%id, 12.6%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu1 : 3.3%us, 7.3%sy, 0.0%ni, 89.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu2 : 18.2%us, 13.9%sy, 0.0%ni, 66.9%id, 0.0%wa, 0.0%hi, 0.0%si, 1.0%st
Cpu3 : 7.3%us, 12.6%sy, 0.0%ni, 80.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Output of mpstat command
[root@xen ~]# mpstat -P ALL 1
Linux 2.6.18-128.1.10.el5xen (xen.pnq.redhat.com) 05/23/2009
04:56:19 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
04:56:20 AM all 9.09 0.00 10.32 0.74 0.00 0.00 0.49 79.36 4929.70
04:56:20 AM 0 10.89 0.00 8.91 0.00 0.00 0.00 0.99 79.21 1289.11
04:56:20 AM 1 2.97 0.00 11.88 2.97 0.00 0.00 0.99 81.19 2083.17
04:56:20 AM 2 13.86 0.00 10.89 0.00 0.00 0.00 0.99 74.26 817.82
04:56:20 AM 3 8.49 0.00 10.38 0.00 0.00 0.00 0.00 81.13 727.72
# top
# mpstat
Notice, after you run the top command, press "1" to get a list of all cores. This will show the actual cup utilization for all the cores.
Example:
Top command run without pressing "1"
Cpu(s): 9.5%us, 12.0%sy, 0.0%ni, 77.9%id, 0.4%wa, 0.0%hi, 0.0%si, 0.2%st
Top command run after pressing "1"
Cpu0 : 2.0%us, 8.0%sy, 0.0%ni, 77.1%id, 12.6%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu1 : 3.3%us, 7.3%sy, 0.0%ni, 89.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu2 : 18.2%us, 13.9%sy, 0.0%ni, 66.9%id, 0.0%wa, 0.0%hi, 0.0%si, 1.0%st
Cpu3 : 7.3%us, 12.6%sy, 0.0%ni, 80.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Output of mpstat command
[root@xen ~]# mpstat -P ALL 1
Linux 2.6.18-128.1.10.el5xen (xen.pnq.redhat.com) 05/23/2009
04:56:19 AM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
04:56:20 AM all 9.09 0.00 10.32 0.74 0.00 0.00 0.49 79.36 4929.70
04:56:20 AM 0 10.89 0.00 8.91 0.00 0.00 0.00 0.99 79.21 1289.11
04:56:20 AM 1 2.97 0.00 11.88 2.97 0.00 0.00 0.99 81.19 2083.17
04:56:20 AM 2 13.86 0.00 10.89 0.00 0.00 0.00 0.99 74.26 817.82
04:56:20 AM 3 8.49 0.00 10.38 0.00 0.00 0.00 0.00 81.13 727.72
Wednesday, December 30, 2009
Instaling a Kernel RPM
# yum install kernel
# rpm -ivh kernel-
Installing a new kernel is one of the few things you will do on your system that requires a reboot of the system. It also requires a little more thought and caution, as it is quite simple to render a system temporarily inoperable if you are careless when updating the kernel. Unlike just about any other upgrade you might do, you should NOT upgrade the kernel using rpm -U or -F.
Recall how rpm functions when upgrading: it determines whether a version already exists on the system, and if so, whether the version to be installed is newer. If it is newer, rpm first installs the new version, thereby replacing old files -- except those marked as configuration files. It then removes the old package, but only deletes files that do not exist in the new version.
Because -U and -F removes the previous kernel version, if your newly-installed kernel proves unstable, you could be left with an unbootable system. You would have to resort to alternate boot media such as a boot floppy or the CD-ROM. When you run an install instead of an upgrade, the old version of the kernel is still available and can be selected from the bootloader. yum knows to perform an “install” rather than an “upgrade” when working with a kernel package, whether you use yum update or yum install.
Because all of the kernel files are version-specific (that is, they either include version details in their names or are stored in version-specific paths), it is possible to install multiple versions of the kernel package. In addition, kernel modules are version-specific, and installation of a new kernel will require re-installation of any add-on kernel modules (not contained in the base package). Missing kernel modules can leave the system unable to dynamically load device drivers or other functions.
By default, the new kernel is automatically added to GRUB and made the default. You can change this behavior by editing /etc/sysconfig/kernel.
# rpm -ivh kernel-
Installing a new kernel is one of the few things you will do on your system that requires a reboot of the system. It also requires a little more thought and caution, as it is quite simple to render a system temporarily inoperable if you are careless when updating the kernel. Unlike just about any other upgrade you might do, you should NOT upgrade the kernel using rpm -U or -F.
Recall how rpm functions when upgrading: it determines whether a version already exists on the system, and if so, whether the version to be installed is newer. If it is newer, rpm first installs the new version, thereby replacing old files -- except those marked as configuration files. It then removes the old package, but only deletes files that do not exist in the new version.
Because -U and -F removes the previous kernel version, if your newly-installed kernel proves unstable, you could be left with an unbootable system. You would have to resort to alternate boot media such as a boot floppy or the CD-ROM. When you run an install instead of an upgrade, the old version of the kernel is still available and can be selected from the bootloader. yum knows to perform an “install” rather than an “upgrade” when working with a kernel package, whether you use yum update or yum install.
Because all of the kernel files are version-specific (that is, they either include version details in their names or are stored in version-specific paths), it is possible to install multiple versions of the kernel package. In addition, kernel modules are version-specific, and installation of a new kernel will require re-installation of any add-on kernel modules (not contained in the base package). Missing kernel modules can leave the system unable to dynamically load device drivers or other functions.
By default, the new kernel is automatically added to GRUB and made the default. You can change this behavior by editing /etc/sysconfig/kernel.
Virtual Memory Behavior in Linux
Introductory Terms:
Virtual Memory: A system that combines physical memory along with some sec-
ondary storage device to give the appearance that a computer system has more
physical memory than is actually installed. A virtual memory system tries to ef-
ficiently allocate physical memory (RAM) among many competing demands, in-
cluding: kernel code, kernel global data, dynamically allocated kernel memory,
kernel caches (buffer, page, swap, and slab), application code, application stack
space, static application memory, and application heap.
Page: Kernel memory management works on top of the computer system hardware
which manipulates memory in units called pages. Page size is determined solely by
the underlying hardware. The page size is 4096 bytes on IA32 hardware platforms.
Buffer Cache: The buffer cache holds filesystem metadata, such as the inode tables,
direct blocks, indirect blocks, journals, superblocks and filesystem bitmaps. Buffer
replacement is triggered by new buffer allocations which cause the VM to evict old
buffers from the system’s inactive list.
Page Cache: This is a read/write cache for files stored on a filesystem. It is re-
ported as Cached when the file /proc/meminfo is consulted. It includes regular
files opened for reading and writing, along with mmaped files, and pages of exe-
cutables currently in memory. (In 2.4.18 and later kernels, the page cache also con-
tains filesystem directories.) In addition, objects which appear in the file system
space but have no associated backing store (such as /proc files, pipes and FIFOs)
use memory in the page cache.
Swap Cache: This is a read/write cache for process data and stack pages that have
been written to the swap device. It is reported as SwapCached when the file
/proc/meminfo is consulted. The swap cache should be considered a virtual
cache, since there is no separate bookkeeping for it in the kernel. It is, however, a
convenient concept, and we shall refer to it in subsequent sections.
Active List: This is a collection of pages which the kernel has determined to be in
active use. The size of this list is reported as Active when the file /proc/meminfo
is consulted.
Inactive List: This set of pages resides in memory, but the kernel has determined
that they are not in active use. These pages are candidates for eviction should the
system come under memory pressure.
Out of Memory Killer (OOM): The OOM is an algorithm which is invoked when the
system senses a potentially fatal shortage of memory. The kernel attempts to kill
processes on a ’most good for least harm’ basis. This algorithm is only invoked
when the system is truly out of memory and swap, and more memory is needed
by the kernel to avoid a deadlock situation.
VM Killer: This algorithm is invoked after a critical shortage of memory has been
detected. It indiscriminately kills the process whose request for memory was im-
mediate and critical to the process, and where the request was impossible to satisfy.
In 2.4.9 and later kernels, this algorithm should never trigger. Such a trigger is con-
sidered a kernel bug. (In experimental kernels, the most commonly seen causes
of the VM killer invocation are poorly written filesystems and pathological VM
implementations.)
Virtual Memory: A system that combines physical memory along with some sec-
ondary storage device to give the appearance that a computer system has more
physical memory than is actually installed. A virtual memory system tries to ef-
ficiently allocate physical memory (RAM) among many competing demands, in-
cluding: kernel code, kernel global data, dynamically allocated kernel memory,
kernel caches (buffer, page, swap, and slab), application code, application stack
space, static application memory, and application heap.
Page: Kernel memory management works on top of the computer system hardware
which manipulates memory in units called pages. Page size is determined solely by
the underlying hardware. The page size is 4096 bytes on IA32 hardware platforms.
Buffer Cache: The buffer cache holds filesystem metadata, such as the inode tables,
direct blocks, indirect blocks, journals, superblocks and filesystem bitmaps. Buffer
replacement is triggered by new buffer allocations which cause the VM to evict old
buffers from the system’s inactive list.
Page Cache: This is a read/write cache for files stored on a filesystem. It is re-
ported as Cached when the file /proc/meminfo is consulted. It includes regular
files opened for reading and writing, along with mmaped files, and pages of exe-
cutables currently in memory. (In 2.4.18 and later kernels, the page cache also con-
tains filesystem directories.) In addition, objects which appear in the file system
space but have no associated backing store (such as /proc files, pipes and FIFOs)
use memory in the page cache.
Swap Cache: This is a read/write cache for process data and stack pages that have
been written to the swap device. It is reported as SwapCached when the file
/proc/meminfo is consulted. The swap cache should be considered a virtual
cache, since there is no separate bookkeeping for it in the kernel. It is, however, a
convenient concept, and we shall refer to it in subsequent sections.
Active List: This is a collection of pages which the kernel has determined to be in
active use. The size of this list is reported as Active when the file /proc/meminfo
is consulted.
Inactive List: This set of pages resides in memory, but the kernel has determined
that they are not in active use. These pages are candidates for eviction should the
system come under memory pressure.
Out of Memory Killer (OOM): The OOM is an algorithm which is invoked when the
system senses a potentially fatal shortage of memory. The kernel attempts to kill
processes on a ’most good for least harm’ basis. This algorithm is only invoked
when the system is truly out of memory and swap, and more memory is needed
by the kernel to avoid a deadlock situation.
VM Killer: This algorithm is invoked after a critical shortage of memory has been
detected. It indiscriminately kills the process whose request for memory was im-
mediate and critical to the process, and where the request was impossible to satisfy.
In 2.4.9 and later kernels, this algorithm should never trigger. Such a trigger is con-
sidered a kernel bug. (In experimental kernels, the most commonly seen causes
of the VM killer invocation are poorly written filesystems and pathological VM
implementations.)
Proc file system
Read-only files:
/proc/ Information on running processes (ps, top)
/proc/cmdline Boot time options
/proc/cpuinfo processor information
/proc/mdstat software RAID information (mdadm)
/proc/meminfo system memory usage (free, vmstat)
/proc/swaps system memory usage (free, vmstat)
/proc/modules dynamically loaded modules (lsmod)
/proc/mounts mounted filesystems (mount)
/proc/net network activity and configuration (ifconfig, netstat)
/proc/partitions block devices known to the kernel
/proc/version version of the Linux kernel (uname)
Read-Write entries:
/proc/sys/kernel/hostname System hostname
/proc/sys/net/ipv4/ip_forward IP Forwarding (on or off)
/proc/sys/vm/drop_caches Writing a 1 forces the kernel to free up some memory from caches.
/proc/sys/vm/swappiness Indicates how aggressively memory will be swapped out to the swap device (number between 0 and 100).
/proc/
/proc/cmdline Boot time options
/proc/cpuinfo processor information
/proc/mdstat software RAID information (mdadm)
/proc/meminfo system memory usage (free, vmstat)
/proc/swaps system memory usage (free, vmstat)
/proc/modules dynamically loaded modules (lsmod)
/proc/mounts mounted filesystems (mount)
/proc/net network activity and configuration (ifconfig, netstat)
/proc/partitions block devices known to the kernel
/proc/version version of the Linux kernel (uname)
Read-Write entries:
/proc/sys/kernel/hostname System hostname
/proc/sys/net/ipv4/ip_forward IP Forwarding (on or off)
/proc/sys/vm/drop_caches Writing a 1 forces the kernel to free up some memory from caches.
/proc/sys/vm/swappiness Indicates how aggressively memory will be swapped out to the swap device (number between 0 and 100).
Kernel Initialization
Kernel boot time functions
• Device detection
• Device driver initialization
• Mounts root filesystem read only
• Loads initial process (init)
The kernel initialization files generate good output, but scroll by quickly. A good way to examine this output is to view /var/log/dmesg, which contains a snapshot of these kernel messages taken just after control is passed to init. Review of this output will reveal the basic initialization steps of the Linux kernel.
Device drivers compiled into the kernel are called, and will attempt to locate their corresponding devices. If successful in locating the device, the driver will initialize and usually log output to the kernel message buffer.
If necessary (needed for boot) drivers have been compiled as modules instead of into the kernel, then they must be included in an initrd image, which is then temporarily mounted by the kernel on a RAM disk to make the modules available for the initialization process.
After all the necessary drivers are loaded, the kernel will mount the root filesystem read-only.
The first process is then loaded (init) and control is passed from the kernel to that process.
• Device detection
• Device driver initialization
• Mounts root filesystem read only
• Loads initial process (init)
The kernel initialization files generate good output, but scroll by quickly. A good way to examine this output is to view /var/log/dmesg, which contains a snapshot of these kernel messages taken just after control is passed to init. Review of this output will reveal the basic initialization steps of the Linux kernel.
Device drivers compiled into the kernel are called, and will attempt to locate their corresponding devices. If successful in locating the device, the driver will initialize and usually log output to the kernel message buffer.
If necessary (needed for boot) drivers have been compiled as modules instead of into the kernel, then they must be included in an initrd image, which is then temporarily mounted by the kernel on a RAM disk to make the modules available for the initialization process.
After all the necessary drivers are loaded, the kernel will mount the root filesystem read-only.
The first process is then loaded (init) and control is passed from the kernel to that process.
Subscribe to:
Posts (Atom)
