The Intent

To determine how large a memory allocation can be made from within the kernel, via the “usual suspects” – the kmalloc and vmalloc kernel memory allocation APIs, in a single call.

Lets answer this question using two approaches: one, reading the source, and two, trying it out empirically on the system.
(Kernel source from kernel ver 3.0.2; tried out on kernel ver 2.6.35 on an x86 PC and 2.6.33.2 on the (ARM) BeagleBoard).

Quick Summary

For the impatient:

The upper limit (number of bytes that can be allocated in a single kmalloc request), is a function of:

• the processor – really, the page size – and
• the number of buddy system freelists (MAX_ORDER).

On both x86 and ARM, with a standard page size of 4 Kb and MAX_ORDER of 11, the kmalloc upper limit is 4 MB!
The vmalloc upper limit is the amount of physical RAM on the system.

The kernel module (can download the source code, see the link at the end of this article), also serves as a decent example of writing pure kernel code.

I kmalloc Limit Tests

First, lets check out the limits for kmalloc :

I Via the Source

From the source: http://lxr.linux.no/linux+v3.0.2/include/linux/slab.h

…

/*
122 * The largest kmalloc size supported by the slab allocators is
123 * 32 megabyte (2^25) or the maximum allocatable page order if that is
124 * less than 32 MB.
125 *
126 * WARNING: Its not easy to increase this value since the allocators have
127 * to do various tricks to work around compiler limitations in order to
128 * ensure proper constant folding.
129 */
130#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT – 1) <= 25 ? \
131                           (MAX_ORDER + PAGE_SHIFT – 1) : 25)
132
133#define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_HIGH)

With MAX_ORDER = 11 and PAGE_SHIFT = 12 (typical case on x86 or ARM with 4K pages), this works out to:
1UL << 22 which is (the same as 2^22) = 4194304 = 4096 KB = 4MB.

II Trying it out

I wanted to verify this experimentally – well, at least the kmalloc() limit (the vmalloc() is hard to verify, as it can use the whole of physical RAM!).

Toward this end, I wrote a small kernel module. It basically does the following:

• Creates and sets up two proc-based “files”
• /proc/driver/kmalloc_test
• /proc/driver/vmalloc_test
• their ‘write’ callbacks are invoked when the user writes a value to the files; this, of course, is expected to be the number of bytes to attempt to allocate using that particular API (kmalloc, in this case).
  Also, realize that we will just do some  arbitrary writes into the region allocated and then (more or less) immediately free it.
• their ‘read’ callbacks are invoked when userspace reads the entry; it merely displays the last attempted number of bytes to allocate…

# dmesg -c
...
#
# insmod ./kvalloc.ko
#
# ls -l /proc/driver/*test*
-rw-r--r-- 1 root root 0 2011-08-16 17:03 /proc/driver/kmalloc_test
-rw-r--r-- 1 root root 0 2011-08-16 17:03 /proc/driver/vmalloc_test
# echo 200000 > /proc/driver/kmalloc_test
# dmesg
[25125.896862] vmall_init_module:260 : Loaded ok.
[25136.659209] kmalloc_procwrite:199 : Successfully allocated via kmalloc 200000 bytes (195 Kb, 0 MB) now to location 0xd5240000 (will kfree..)
#
# echo 2000008 > /proc/driver/vmalloc_test
# dmesg
[25125.896862] vmall_init_module:260 : Loaded ok.
[25136.659209] kmalloc_procwrite:199 : Successfully allocated via kmalloc 200000 bytes (195 Kb, 0 MB) now to location 0xd5240000 (will kfree..)
[25162.082120] vmalloc_procwrite:129 : Successfully allocated via vmalloc 2000008 bytes (1953 Kb, 1 MB) now to location 0xe0ac5000 (will vfree..)
#

As can be seen, the driver was loaded, the proc files were created, and two successful allocations were performed.
Of course, one can’t be expected to keep doing this manually till we hit a limit…so, we’ll use a simple shell script to help automate this task.
The script will basically loop, allocating a given amount of RAM (x bytes), adding a  step factor to it (x+step) and doing it again, in a loop…

We pass ‘k’ or ‘v’ to the script as a parameter, telling it whether to test the kmalloc or vmalloc API limit. We can also pass optional parameters, starting size and ‘step factor’.

# ./test_kvalloc.sh
Usage: test_kvalloc.sh {k|v} [start_numbytes] [step_factor]
 k : test the KMALLOC limit
 v : test the VMALLOC limit
# 

Testing kmalloc limit

So, lets do a test run for kmalloc, starting at 300 Kb in steps of 500 Kb.

# dmesg -c
…
# ./test_kvalloc.sh k 307200 512000
KVALLOC_PROCFILE = /proc/driver/kmalloc_test

Running:
KMALLOC TEST
test_kvalloc.sh 307200 512000

Attempting to alloc 307200 bytes (300 KB, 0 MB)
Attempting to alloc 819200 bytes (800 KB, 0 MB)
Attempting to alloc 1331200 bytes (1300 KB, 1 MB)
Attempting to alloc 1843200 bytes (1800 KB, 1 MB)
Attempting to alloc 2355200 bytes (2300 KB, 2 MB)
Attempting to alloc 2867200 bytes (2800 KB, 2 MB)
Attempting to alloc 3379200 bytes (3300 KB, 3 MB)
Attempting to alloc 3891200 bytes (3800 KB, 3 MB)
Attempting to alloc 4403200 bytes (4300 KB, 4 MB)
./test_kvalloc.sh: line 46: echo: write error: Cannot allocate memory
FAILURE! AT 4403200 bytes = 4300 KB = 4 MB. Aborting…
#

Yes, it fails at ~ 4 MB.

# dmesg
[25647.216149] kmalloc_procwrite:199 : Successfully allocated via kmalloc 307200 bytes (300 Kb, 0 MB) now to location 0xc0f80000 (will kfree..)
[25647.223584] kmalloc_procwrite:199 : Successfully allocated via kmalloc 819200 bytes (800 Kb, 0 MB) now to location 0xdce00000 (will kfree..)
[25647.321891] kmalloc_procwrite:199 : Successfully allocated via kmalloc 1331200 bytes (1300 Kb, 1 MB) now to location 0xdcc00000 (will kfree..)
[25647.329913] kmalloc_procwrite:199 : Successfully allocated via kmalloc 1843200 bytes (1800 Kb, 1 MB) now to location 0xdcc00000 (will kfree..)
[25647.336471] kmalloc_procwrite:199 : Successfully allocated via kmalloc 2355200 bytes (2300 Kb, 2 MB) now to location 0xdc000000 (will kfree..)
[25647.397678] kmalloc_procwrite:199 : Successfully allocated via kmalloc 2867200 bytes (2800 Kb, 2 MB) now to location 0xdc000000 (will kfree..)
[25647.398845] kmalloc_procwrite:199 : Successfully allocated via kmalloc 3379200 bytes (3300 Kb, 3 MB) now to location 0xdc000000 (will kfree..)
[25647.400119] kmalloc_procwrite:199 : Successfully allocated via kmalloc 3891200 bytes (3800 Kb, 3 MB) now to location 0xdc000000 (will kfree..)
[25647.401443] ————[ cut here ]————
[25647.401598] WARNING: at /build/buildd/linux-2.6.35/mm/page_alloc.c:2005 __alloc_pages_slowpath+0x36d/0x4b0()
[25647.401624] Hardware name: VMware Virtual Platform
[25647.401625] Modules linked in: kvalloc nls_iso8859_1 nls_cp437 vfat fat usb_storage cdc_acm vmblock vsock vmhgfs acpiphp binfmt_misc snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi ppdev snd_seq_midi_event snd_seq vmware_balloon snd_timer snd_seq_device psmouse serio_raw parport_pc snd soundcore snd_page_alloc intel_agp lp agpgart vmci i2c_piix4 shpchp parport mptspi mptscsih floppy mptbase scsi_transport_spi vmxnet [last unloaded: kvalloc]
[25647.401674] Pid: 6395, comm: test_kvalloc.sh Not tainted 2.6.35-30-generic #56-Ubuntu
[25647.401676] Call Trace:
[25647.401723] [<c014b602>] warn_slowpath_common+0×72/0xa0
[25647.401729] [<c01e0a5d>] ? __alloc_pages_slowpath+0x36d/0x4b0
[25647.401732] [<c01e0a5d>] ? __alloc_pages_slowpath+0x36d/0x4b0
[25647.401735] [<c014b652>] warn_slowpath_null+0×22/0×30
[25647.401750] [<c01e0a5d>] __alloc_pages_slowpath+0x36d/0x4b0
[25647.401753] [<c01e03c7>] ? get_page_from_freelist+0×247/0×330
[25647.401756] [<c01e0d0f>] __alloc_pages_nodemask+0x16f/0x1c0
[25647.401759] [<c01e0d7c>] __get_free_pages+0x1c/0×30
[25647.401785] [<c020e196>] __kmalloc+0×146/0×170
[25647.401799] [<c0231c6f>] ? mntput_no_expire+0x1f/0xd0
[25647.401803] [<e0a493ca>] kmalloc_procwrite+0x7a/0x1d8 [kvalloc]
[25647.401848] [<c02644d3>] proc_file_write+0×63/0xa0
[25647.401851] [<c0264470>] ? proc_file_write+0×0/0xa0
[25647.401854] [<c025f4f7>] proc_reg_write+0×67/0xa0
[25647.401868] [<c023069d>] ? alloc_fd+0xbd/0xf0
[25647.401872] [<c0219ab2>] vfs_write+0xa2/0×190
[25647.401875] [<c025f490>] ? proc_reg_write+0×0/0xa0
[25647.401878] [<c021a372>] sys_write+0×42/0×70
[25647.401923] [<c05cc284>] syscall_call+0×7/0xb
[25647.401925] —[ end trace b6b188c8bd2758df ]—
[25647.401927] kvalloc: kmalloc of 4403200 bytes FAILED!
#

Testing the same on the BeagleBoard (running 2.6.33.2 Linux on a TI OMAP3 ARM Cortex-A8 processor, 256 MB RAM):

On the board, after inserting the kernel module, we run the shell script:

root@beagleboard:/media/mmcblk0p1# ./test_kvalloc.arm.sh k 50000 102400
KVALLOC_PROCFILE = /proc/driver/kmalloc_test

Running:
KMALLOC TEST
test_kvalloc.arm.sh 50000 102400

Attempting to alloc 50000 bytes (48 KB, 0 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 50000 bytes (48 Kb, 0 MB) now to location 0xc2c40000 (will kfr
ee..)
Attempting to alloc 152400 bytes (148 KB, 0 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 152400 bytes (148 Kb, 0 MB) now to location 0xcd400000 (will k
free..)
Attempting to alloc 254800 bytes (248 KB, 0 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 254800 bytes (248 Kb, 0 MB) now to location 0xcd400000 (will k
free..)
Attempting to alloc 357200 bytes (348 KB, 0 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 357200 bytes (348 Kb, 0 MB) now to location 0xcf980000 (will k
free..)
...
...
Attempting to alloc 3838800 bytes (3748 KB, 3 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 3838800 bytes (3748 Kb, 3 MB) now to location 0xcd800000 (will
 kfree..)
Attempting to alloc 3941200 bytes (3848 KB, 3 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 3941200 bytes (3848 Kb, 3 MB) now to location 0xcd800000 (will
 kfree..)
Attempting to alloc 4043600 bytes (3948 KB, 3 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 4043600 bytes (3948 Kb, 3 MB) now to location 0xcd800000 (will
 kfree..)
Attempting to alloc 4146000 bytes (4048 KB, 3 MB)
kmalloc_procwrite:199 : Successfully allocated via kmalloc 4146000 bytes (4048 Kb, 3 MB) now to location 0xcd800000 (will
 kfree..)
Attempting to alloc 4248400 bytes (4148 KB, 4 MB)
kvalloc: kmalloc of 4248400 bytes FAILED!
root@beagleboard:/media/mmcblk0p1#

Clearly, and as expected, the kmalloc() fails at the 4 Mb allocation attempt (just as on the x86)!

———————————————————————————————————————————————–

II vmalloc Limit Tests

Now, lets check out the limits for vmalloc :

I Via the Source

A quick perusal of the source (start at mm/vmalloc.c), shows the call graph for vmalloc is (approximately, at least):

vmalloc –> __vmalloc_node_flags –> __vmalloc_node –> __vmalloc_node_range

[ a --> b above implies function a() calls function b() ].

In the function __vmalloc_node_range()  (code pasted below from the lxr.linux.no website):

...
void *__vmalloc_node_range(unsigned long size, unsigned long align,
1607                        unsigned long start, unsigned long end, gfp_t gfp_mask,
1608                        pgprot_t prot, int node, void *caller)
1609{
1610        struct vm_struct *area;
1611        void *addr;
1612        unsigned long real_size = size;
1613
1614        size = PAGE_ALIGN(size);
1615        if (!size || (size >> PAGE_SHIFT) > totalram_pages)
1616                return NULL;
1617

Line 1615 above tells us:

if the size is zero OR if the size expressed in pages is greater than totalram_pages, then abort; it’s invalid.
So there’s our answer: the vmalloc API limit is the size of physical RAM!

Of course, budding kernel developers, please (read, for God’s sake!!!) note:
Do NOT abuse this API by allocating huge amounts of RAM just because you can; you will hurt the kernel’s performance like heck and no one will use your driver! It’s true…

II Trying it out

Running on Ubuntu 10.04 with a 2.6.35 kernel, on the VMware VM, we have this much RAM:

# grep -i memtotal /proc/meminfo
MemTotal:         508396 kB
#

i.e. ~  496 MB of RAM.

We run the same shell script as above, this time with the ‘v’ parameter and a larger initial size (lets try 500 Kb) and ‘step factor’ (lets go with 5 Mb – that means we’ll attempt to alloc in steps of 5 Mb !):

…

…

vmalloc limit test 2

…
I find that vmalloc successfully allocates (and of course subsequently deallocates) upto ~ 455 MB at one shot (remember, on this VM system total RAM is 496 MB) before the virtual machine itself seems to hang. In reality, the kernel is doing it’s very best to allocate RAM as requested. In fact, it does succeed…until RAM runs out!

The Linux OS design is such that, when RAM is falling short, the kernel will do it’s damn-dest to reclaim RAM, aggressively swapping as necessary. What if this does not help? What if some malicious or greedy app(s) keep allocating memory!? – like we do here: we just keep eating RAM with vmalloc()! Well, when the kernel hits a dead-end, i.e., when both RAM and swap space are (almost) exhausted, the kernel takes a decision: it can either die or kill the bad guy; guess which it does

The OOM (Out Of Memory) Killer runs, killing off the “bad” tasks!
That’s exactly what happens here: we don’t give the kernel much choice, do we!

Notice how this is a very different case from how the kmalloc() fails : it fails on hitting an artificially set limit, with no fuss or fanfare. The vmalloc(), on the other hand, hogs so much RAM, that it inadvertently causes the OOM Killer to run, killing the memory hoggers as a side effect, rather than failing directly due to the size limit being hit.

The screenshots above show the situation before the OOM-killer hits.

[ These tests have been run on Ubuntu 10.04, running a 2.6.35 kernel on the VMware Workstation VM product ].

Testing the same on the BeagleBoard (running 2.6.33.2 Linux on a TI OMAP3 ARM Cortex-A8 processor, 256 MB RAM):

The BeagleBoard I’m using (rev C3), has 256 MB RAM. On the board, after inserting the kernel module, we run the shell script, this time with the ‘v’ parameter and a larger initial size (lets try 500 Kb) and ‘step factor’ (lets go with 5 Mb – that means we’ll attempt to alloc in steps of 5 Mb !):

root@beagleboard:/media/mmcblk0p1# ./test_kvalloc.arm.sh
Usage: test_kvalloc.arm.sh {k|v} [start_numbytes] [step_factor]
 k : test the KMALLOC limit
 v : test the VMALLOC limit
root@beagleboard:/media/mmcblk0p1# ./test_kvalloc.arm.sh v 500000 5242880
KVALLOC_PROCFILE = /proc/driver/vmalloc_test

Running:
VMALLOC TEST
test_kvalloc.arm.sh 500000 5242880

Attempting to alloc 500000 bytes (488 KB, 0 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 500000 bytes (488 Kb, 0 MB) now to location 0xd0871000 (will v
free..)
Attempting to alloc 5742880 bytes (5608 KB, 5 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 5742880 bytes (5608 Kb, 5 MB) now to location 0xd08ee000 (will
 vfree..)
Attempting to alloc 10985760 bytes (10728 KB, 10 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 10985760 bytes (10728 Kb, 10 MB) now to location 0xd0e6f000 (w
ill vfree..)
Attempting to alloc 16228640 bytes (15848 KB, 15 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 16228640 bytes (15848 Kb, 15 MB) now to location 0xd18f1000 (w
ill vfree..)
...
...
Attempting to alloc 220700960 bytes (215528 KB, 210 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 220700960 bytes (215528 Kb, 210 MB) now to location 0xd088e000
 (will vfree..)
Attempting to alloc 225943840 bytes (220648 KB, 215 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 225943840 bytes (220648 Kb, 215 MB) now to location 0xddb42000
 (will vfree..)
Attempting to alloc 231186720 bytes (225768 KB, 220 MB)
vmalloc_procwrite:129 : Successfully allocated via vmalloc 231186720 bytes (225768 Kb, 220 MB) now to location 0xd0890000
 (will vfree..)
Attempting to alloc 236429600 bytes (230888 KB, 225 MB)
echo invoked oom-killer: gfp_mask=0xd2, order=0, oom_adj=0
[<c002e3a0>] (unwind_backtrace+0x0/0xd4) from [<c007c700>] (T.280+0x3c/0x108)
[<c007c700>] (T.280+0x3c/0x108) from [<c007c804>] (T.277+0x38/0xd8)
[<c007c804>] (T.277+0x38/0xd8) from [<c007c9f8>] (__out_of_memory+0x154/0x178)
[<c007c9f8>] (__out_of_memory+0x154/0x178) from [<c007ca9c>] (out_of_memory+0x80/0xb4)
[<c007ca9c>] (out_of_memory+0x80/0xb4) from [<c007f208>] (__alloc_pages_nodemask+0x418/0x514)
[<c007f208>] (__alloc_pages_nodemask+0x418/0x514) from [<c0095678>] (__vmalloc_area_node+0xbc/0x11c)
[<c0095678>] (__vmalloc_area_node+0xbc/0x11c) from [<c00958b8>] (vmalloc+0x24/0x2c)
[<c00958b8>] (vmalloc+0x24/0x2c) from [<bf000140>] (vmalloc_procwrite+0xf4/0x190 [kvalloc])
[<bf000140>] (vmalloc_procwrite+0xf4/0x190 [kvalloc]) from [<c00dd100>] (proc_file_write+0x3c/0x58)
[<c00dd100>] (proc_file_write+0x3c/0x58) from [<c00d94ec>] (proc_reg_write+0x40/0x54)
[<c00d94ec>] (proc_reg_write+0x40/0x54) from [<c009e490>] (vfs_write+0xac/0x154)
[<c009e490>] (vfs_write+0xac/0x154) from [<c009e5e4>] (sys_write+0x3c/0x68)
[<c009e5e4>] (sys_write+0x3c/0x68) from [<c0028dc0>] (ret_fast_syscall+0x0/0x2c)
Mem-info:
Normal per-cpu:
CPU    0: hi:   90, btch:  15 usd:  97
...
...
0 pages swap cached
Out of memory: kill process 991 (sh) score 65 or a child
Killed process 2533 (test_kvalloc.ar) vsz:2676kB, anon-rss:72kB, file-rss:0kB
echo invoked oom-killer: gfp_mask=0xd2, order=0, oom_adj=0
[<c002e3a0>] (unwind_backtrace+0x0/0xd4) from [<c007c700>] (T.280+0x3c/0x108)
[<c007c700>] (T.280+0x3c/0x108) from [<c007c804>] (T.277+0x38/0xd8)
[<c007c804>] (T.277+0x38/0xd8) from [<c007c9f8>] (__out_of_memory+0x154/0x178)
[<c007c9f8>] (__out_of_memory+0x154/0x178) from [<c007ca9c>] (out_of_memory+0x80/0xb4)
...
...
Out of memory: kill process 991 (sh) score 44 or a child
Killed process 991 (sh) vsz:2852kB, anon-rss:112kB, file-rss:24kB
echo invoked oom-killer: gfp_mask=0xd2, order=0, oom_adj=0
...
...
Out of memory: kill process 986 (syslogd) score 42 or a child
Killed process 986 (syslogd) vsz:2740kB, anon-rss:60kB, file-rss:64kB
...
...

So, we can see from above, that at the 225 MB allocation attempt it failed; the kernel OOM-killer jumped in and rapidly finished off the shell script, the shell process, syslogd…
After that, I aborted the script and the login process re-ran (because init would have re-spawned it) and I received the login prompt again.

=============================================================================================================================================

As an aside, this kernel module serves as a decent example of writing some pure kernel code (not driver related): it is concurrent-safe, and implements the useful notion of a global “context / device” structure accessed via a single global pointer that is passed around. This helps with code maintenance and debugging as well…It is also small enough to read quickly and grasp the essentials.

Please do comment with your inputs!

Download the source tarball (tar.gz) here.

The Linux RT signals can be seen with the usual ‘kill’ command.

[As can be seen from the command output, am running on an Ubuntu 10.10 Linux box, with libc ver 2.12.1]:

$ cat /etc/issue
Ubuntu 10.10 \n \l

$ uname -r
2.6.35-28-generic

$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 14 2011-02-03 09:49 /lib/libc.so.6 -> libc-2.12.1.so*
$
$ kill -l
1) SIGHUP     2) SIGINT     3) SIGQUIT     4) SIGILL     5) SIGTRAP 6) SIGABRT     7) SIGBUS     8) SIGFPE     9) SIGKILL    10) SIGUSR1 11) SIGSEGV    12) SIGUSR2    13) SIGPIPE    14) SIGALRM    15) SIGTERM 16) SIGSTKFLT    17) SIGCHLD    18) SIGCONT    19) SIGSTOP    20) SIGTSTP 21) SIGTTIN    22) SIGTTOU    23) SIGURG    24) SIGXCPU    25) SIGXFSZ 26) SIGVTALRM    27) SIGPROF    28) SIGWINCH    29) SIGIO    30) SIGPWR 31) SIGSYS    34) SIGRTMIN    35) SIGRTMIN+1    36) SIGRTMIN+2    37) SIGRTMIN+3 38) SIGRTMIN+4    39) SIGRTMIN+5    40) SIGRTMIN+6    41) SIGRTMIN+7    42) SIGRTMIN+8 43) SIGRTMIN+9    44) SIGRTMIN+10    45) SIGRTMIN+11    46) SIGRTMIN+12    47) SIGRTMIN+13 48) SIGRTMIN+14    49) SIGRTMIN+15    50) SIGRTMAX-14    51) SIGRTMAX-13    52) SIGRTMAX-12 53) SIGRTMAX-11    54) SIGRTMAX-10    55) SIGRTMAX-9    56) SIGRTMAX-8    57) SIGRTMAX-7 58) SIGRTMAX-6    59) SIGRTMAX-5    60) SIGRTMAX-4    61) SIGRTMAX-3    62) SIGRTMAX-2 63) SIGRTMAX-1    64) SIGRTMAX
$

RT signals above are highlighted in blue colour.

There is (was?) some confusion (different opinions in texts, manuals) as to the prioritisation of queued R signals; is SIGRMIN the lowest priority signal (seems intuitive).

Turns out this is not the case (as I’ve empirically verified): the top priority RT signal isSIGRTMIN; least (worst) priority RT sig is SIGRTMAX.

Source: the man page on signal(7):

...

Real-time Signals
Linux supports real-time signals as originally defined in the POSIX.1b real-time extensions (and now included in  POSIX.1-2001).
The  range  of supported real-time signals is defined by the macros SIGRTMIN and SIGRTMAX.

...

Real-time signals are distinguished by the following:

1.  Multiple  instances  of real-time signals can be queued.  By contrast, if multiple instances of a standard signal are deliv‐
ered while that signal is currently blocked, then only one instance is queued.

2.  If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If  the receiving process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of the siginfo_t structure passed as the second argument to the handler.  Furthermore,  the si_pid and si_uid fields of this structure can be used to obtain the PID and real user ID of the process sending the signal.

3.  Real-time  signals  are  delivered  in a guaranteed order.  Multiple real-time signals of the same type are delivered in the order they were sent.  If different real-time signals are sent to a process, they are delivered starting  with  the  lowest-numbered signal.  (I.e., low-numbered signals have highest priority.) By contrast, if multiple standard signals are pending for a process, the order in which they are delivered is unspecified.

If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first.   Linux, like many other implementations, gives priority to standard signals in this case.

…

So that settles it.

I came in late; heard an interesting session by Askhay Dashrath (the lead organizer).

Was asked by Bhavya to talk about something on Android, so gave a presentation on ‘Android: A Look Under the Hood’.
The coverage included:

• how Android is different from a “typical” embedded Linux device / product
• Android Architecture
• Google’s Android enhancements to the Linux kernel
• brief demo on a device using ‘adb shell’

The session was well received, with a good number of questions from participants.

The presentation docs were subsequently uploaded and are available here.

An enjoyable and enlightening time for me as well!

A (small) part of the Linux VFS module of the Designer Graphix Linux Internals training programme.

Referenced kernel ver: 2.6.30

Once extracted, see the

 fs/fat

folder.

_Tip:_
For ease of code browsing, do ‘make tags’ (or ‘ctags -R’) in the root folder of the kernel soure tree.

cd fs/fat

Note: Here the focus is on part of the MSDOS – Linux VFS kernel implementation, mainly the disk-related part, i.e., the superblock and inode objects. We don’t attempt to cover the Dcache/dentry, page cache (address operations) and just touch upon the process<–>filesystem relationship stuff (at least for now).

_Tip:_
To gain some insight into the physical structure / arch of the MSDOS (and [v]fat) filesystem, see this page.
The <linux/msdos_fs.h> header mirrors much of this.

For example, the FAT16 boot record (boot sector) structure is nicely seen here; it’s Linux layout is here:
include/linux/msdos_fs.h:struct fat_boot_sector
(can browse it via the superb LXR tool here).

Superblock Setup

In namei_msdos.c:


...
static struct file_system_type msdos_fs_type = {
.owner          = THIS_MODULE,
.name           = "msdos",
.get_sb         = msdos_get_sb,
.kill_sb        = kill_block_super,
.fs_flags       = FS_REQUIRES_DEV,
};

static int __init init_msdos_fs(void)
{
return register_filesystem(&msdos_fs_type);
}
…

So, the routine invoked upon mounting is msdos_get_sb :

Following the call chain in msdos_get_sb (see the flow diagram), control hits VFS fill_super routine, which implicitly invokes the msdos_fill_super routine (function pointer passed via a parameter). This is the MSDOS-filesystem-specific routine to initialize the superblock.

This invokes the fat_fill_super routine which actually allocates memory for and initializes the MSDOS superblock structure – struct msdos_sb_info ; this is the data structure that MSDOS FS uses to map it’s filesystem superblock into the kernel’s VFS struct super_block structure. This routine reads from disk the MSDOS superblock, parses mount options, makes validity checks on the filesystem superblock, and finally intializes the structure.

...
sb->s_magic = MSDOS_SUPER_MAGIC;
sb->s_op = &fat_sops;
sb->s_export_op = &fat_export_ops;
sbi->dir_ops = fs_dir_inode_ops;
<< sbi is the msdos_sb_info structure >>
...
bh = sb_bread(sb, 0); << Block read off disk, sector 0 - boot sector >>
if (bh == NULL) {
printk(KERN_ERR "FAT: unable to read boot sector\n");
goto out_fail;
}

b = (struct fat_boot_sector *) bh->b_data;
…

sbi->cluster_size = sb->s_blocksize * sbi->sec_per_clus; << Init msdos superblock >>
sbi->cluster_bits = ffs(sbi->cluster_size) – 1;
sbi->fats = b->fats;
sbi->fat_bits = 0; /* Don’t know yet */
sbi->fat_start = le16_to_cpu(b->reserved);
sbi->fat_length = le16_to_cpu(b->fat_length);
sbi->root_cluster = 0;
sbi->free_clusters = -1; /* Don’t know yet */
sbi->free_clus_valid = 0;
sbi->prev_free = FAT_START_ENT;

if (!sbi->fat_length && b->fat32_length) {
struct fat_boot_fsinfo *fsinfo;
struct buffer_head *fsinfo_bh;

/* Must be FAT32 */
sbi->fat_bits = 32;
sbi->fat_length = le32_to_cpu(b->fat32_length);
sbi->root_cluster = le32_to_cpu(b->root_cluster);
…

It then sets up the root inode as well (including getting the superblock’s s_root field to point to the root inode.

...
root_inode = new_inode(sb);
if (!root_inode)
goto out_fail;
root_inode->i_ino = MSDOS_ROOT_INO;
root_inode->i_version = 1;
error = fat_read_root(root_inode);
if (error < 0)
goto out_fail;
error = -ENOMEM;
insert_inode_hash(root_inode);
sb->s_root = d_alloc_root(root_inode);
...

Inodes Setup

The inode represents any kind of file object. However, the VFS distinguishes between inode operations to be enacted on a directory object versus those to be enacted on a regular file (I/O) object.

So we have two ‘inode_operations’ structures that the filesystem implements – one for directory operations – creation, deletion, lookup, rename, etc – anything that operates directly on a “directory” (think “.” file) object, and one ‘inode_operations’ structure for actual file IO.

Inode Create and Init

Whenever a new file is created, the filesystem has to allocate an inode. The ‘alloc_inode’ method of the superblock’s super_operations does this.
For MSDOS, we have (infs/fat/inode.c):


static const struct super_operations fat_sops = {
.alloc_inode = fat_alloc_inode,
.destroy_inode  = fat_destroy_inode,
.write_inode    = fat_write_inode,
.delete_inode   = fat_delete_inode,
.put_super      = fat_put_super,
.write_super    = fat_write_super,
.statfs         = fat_statfs,
.clear_inode    = fat_clear_inode,
.remount_fs     = fat_remount,
.show_options   = fat_show_options,
};

...

The fs/inode.c:new_inode() routine is invoked to obtain a new inode.
It in turn, invokes the alloc_inode() routine.

static struct inode *alloc_inode(struct super_block *sb)
{
struct inode *inode;

if (sb->s_op->alloc_inode)
inode = sb->s_op->alloc_inode(sb);
else
inode = kmem_cache_alloc(inode_cachep, GFP_KERNEL);

if (inode)
return inode_init_always(sb, inode);
return NULL;
}
So, we can see that alloc_inode invokes the filesystem-specific method from the filesystem’s superblock operations.
This is the ‘fat_alloc_inode‘ method (see the fat_sops structure above):

In fs/fat/inode.c :
...
static struct kmem_cache *fat_inode_cachep;

static struct inode *fat_alloc_inode(struct super_block *sb)
{
struct msdos_inode_info *ei;
ei = kmem_cache_alloc(fat_inode_cachep, GFP_NOFS);
if (!ei)
return NULL;
return &ei->vfs_inode;
}
…
Notice how a custom slab cache (to hold MSDOS inode objects) is used to rapidly perform the allocation (& subsequent free back into the cache).

The MSDOS/FAT Directory Inode Operations

Initialize an inode:
The ‘create’ method of the file_operations structure, therefore, is setup to point to a method to do this for the particular filesystem implementation.

So, we see in fs/fat/namei_msdos.c :

static const struct inode_operations msdos_dir_inode_operations = {
        .create         = msdos_create,
        .lookup         = msdos_lookup,
        .unlink         = msdos_unlink,
        .mkdir          = msdos_mkdir,
        .rmdir          = msdos_rmdir,
        .rename         = msdos_rename,
        .setattr        = fat_setattr,
        .getattr        = fat_getattr,
};

static int msdos_fill_super(struct super_block *sb, void *data, int silent)
{
        int res; 
        res = fat_fill_super(sb, data, silent, &msdos_dir_inode_operations, 0);
...

fs/fat/inode.c:

…


/*
* Read the super block of an MS-DOS FS.
*/
int fat_fill_super(struct super_block *sb, void *data, int silent,
const struct inode_operations *fs_dir_inode_ops, int isvfat)
{
...
sbi->dir_ops = fs_dir_inode_ops;
...

If a userspace process attempts to create a new file on an MSDOS filesystem, the kernel VFS ultimately switches the request to the fs_dir_inode_ops function, in this case, the create method which is msdos_create.

The MSDOS/FAT File Inode Operations

In fs/fat/inode.c :

The fat_fill_inode routine [1] is the one responsible for initializing the inode, for both a directory object as well as a non-directory object.

...
/* doesn't deal with root inode */
static int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
{
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
...
if ((de->attr & ATTR_DIR) && !IS_FREE(de->name)) {
inode->i_generation &= ~1;
inode->i_mode = fat_make_mode(sbi, de->attr, S_IRWXUGO);
inode->i_op = sbi->dir_ops;
<< sbi->dir_ops is the same structure we saw above, viz,
the msdos_dir_inode_operations structure. >>
inode->i_fop = &fat_dir_operations;

...
} else { /* not a directory */
inode->i_generation |= 1;
inode->i_mode = fat_make_mode(sbi, de->attr,
((sbi->options.showexec && !is_exec(de->name + 8))
? S_IRUGO|S_IWUGO : S_IRWXUGO));
MSDOS_I(inode)->i_start = le16_to_cpu(de->start);
if (sbi->fat_bits == 32)
MSDOS_I(inode)->i_start |= (le16_to_cpu(de->starthi) << 16);

MSDOS_I(inode)->i_logstart = MSDOS_I(inode)->i_start;
inode->i_size = le32_to_cpu(de->size);
inode->i_op = &fat_file_inode_operations;
inode->i_fop = &fat_file_operations;
inode->i_mapping->a_ops = &fat_aops;
…

It first switches on whether the ‘file object’ to be created is a directory or not.
Furthermore, as we can see above, the inode has two operation pointers:

i_op: for the inode methods operating on the inode object itself, and

i_fop: for the methods that operate on the open file object that the inode represents.

In fs/fat/file.c :

...
const struct inode_operations fat_file_inode_operations = {
.truncate = fat_truncate,
.setattr = fat_setattr,
.getattr = fat_getattr,
};

In fs/fat/file.c :

...
const struct file_operations fat_file_operations = {
.llseek = generic_file_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
.mmap = generic_file_mmap,
.release = fat_file_release,
.ioctl = fat_generic_ioctl,
.fsync = file_fsync,
.splice_read = generic_file_splice_read,
};

…

These will be invoked via the usual VFS route (filp->f_op->foo), where foo is the method – system call – invoked from the userspace process (or thread).

In fact, we can see from the above implementation, that the MSDOS filesystem (and indeed all the FAT variants – MSDOS (FAT12), FAT16, FAT32 (VFAT)), invoke the generic VFS methods for read, write, lseek, mmap and aio_[read|write].
Which, of course, is in a large sense, the whole point: once the underlying filesystem “driver” (such as MSDOS or FAT) maps it’s physical structure to the kernel VFS expectations – to it’s (VFS’s) data structures, the kernel goes ahead and treats it as a (virtual) filesystem; I/O proceeds using the mechanisms built-in.

VFS component

Corr. MSDOS/FAT component

Macro to access it

struct super_block

struct msdos_sb_info

MSDOS_SB

struct inode

struct msdos_inode_info

MSDOS_I

[1] When does the fat_fill_inode routine get invoked?

The fat_build_inode function invokes it. So what invokes fat_build_inode ?

cscope can provide us with an answer (output below, on the 2.6.30 kernel):

Functions calling this function: fat_build_inode

  File          Function       Line
0 inode.c       fat_get_parent 752 inode = fat_build_inode(sb, de, i_pos);
1 namei_msdos.c msdos_lookup   220 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
2 namei_msdos.c msdos_create   306 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
3 namei_msdos.c msdos_mkdir    394 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
4 namei_vfat.c  vfat_lookup    732 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
5 namei_vfat.c  vfat_create    788 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);
6 namei_vfat.c  vfat_mkdir     882 inode = fat_build_inode(sb, sinfo.de, sinfo.i_pos);

(c) 2009 Kaiwan N Billimoria, Designer Graphix.

Yup. Pretty much a given..

Google says we’ll easily have around 18 Android ‘phones by year end.
So?

Please read this excellent NY Times article first (opens in a new window), and then continue here, if it so pleases you…

Well, I don’t know about you but am a bit taken aback by (Google’s) Andy Rubin’s statement regarding the three options that handset OEMs and wireless carriers have.

In effect, the first options says (and I’d love someone to correct me if i’m reading it wrong here)- take it completely free but don’t touch (preload) our (Google) apps; the second “small strings” option says- sign a distribution agreement with us and all’s cool. Hmm, can we see this agreement? Third option “no-censorship” aka “The Google Experience” phones- so, looks like there is after all, a Google Phone . Right? I mean, Google logo on the device and all.

Initially my impression was that Google is indeed trying to “distance” itself from the platform. “Hey, it’s open- we built it, now do what you like okay”. Now that, apparently, looks to be not-so-true.

Still, this is not necessarily “a bad thing”. Okay Google is (starting to) leveraging it’s considerable strength with Android. It’s still an open platform. Yes. But… one just wonders..

Well, we’ll wait and see…
hope to keep you posted!

Now it’s “official”.

Motorola is newly wed to the Android platform.

They’ve put up a nice aggregate (tutorials, etc) site.

So far, I have not (personally) seen/used a really great Android phone (or device). In the hardware sense of course (the software platform simply rocks!). I mean, the camera on the G1 (I use the ADP1, completely equivalent) is terrible when I compare it with a Nokia N-series phone, for example…

I think this limitation will now be addressed: Samsung already has an Android smartphone out, now Motorola looks set to release one this year; interestingly, Motorola definitely seems to be looking to leverage the vast open-source community already around the Android platform via their developer site. Good going! -much much nicer than what they did at first with their (early) Motorola-Linux platform(s).

We wish them luck. The more the merrier. The better it gets- for Android, the OEMs, and of course, us.

Was appreciated in general…
Some details.

So, among my Best Android Apps are:
Built-in: Contacts (w/ gmail), gmail, (google) calendar,
Sync: 3Banana, twitdroid.
LBS: GPS Status, MyTracks, Compass, SnapPhoto,
Misc: ASTRO, Useful Switchers, ToggleBlu

More to follow…

Ok, an update (6 Oct ’09):

Widgets:

Internal Memory Widget : useful to see how much space remains on internal flash (as all apps get installed there).

MoonPhase : as it says, and really done nicely.

Retro Clock & Date : …neat.

PowerManager : wow. Just what the doc ordered; really helps when your batt is low… of course you can create/edit power profiles. A must!

LastPass : the final word on “not having to remember those damned username/password pairs ever again”! Love it! Make sure you use it in Firefox/IE as well…

MyBackup : looks good, have yet to test restore…

Proxoid: I use this to tether my phone to the PC so I can browse via the phone’s GPRS conection…
works well on Linux!

ContactSender : Very unfortunately, Android (& it seems Linux-based phones in general) can’t seem to understand the Vcard protocol for sharing contacts (hope I’m wrong here, pl tell me if so!). So this guy at least lets you conveniently send an SMS to someone w/ the contact info you pick.

Quick Uninstall

SkyMap : wow. Trust google.

Wapedia : really fast wikipedia browser, good no-nonsense UI too.

ToddlerLock : awesome for small kids who can’t keep their paws off!

ShopSavvy :

Wikitude : both Wows! A little over the top but hey it’s the future dude!

Know of other awesome apps? Pl comment now!

LINUX Quick Reference Cheat Sheet

vmstat, ps, top

v 0.1 : Last Updated: March 2009 : <kaiwan at designergraphix dot com>
(c) kaiwan billimoria.

Much of the information below gleaned from various Linux man pages.

———————————————————-

vmstat

vmstat fields quick reference

The -a switch displays active/inactive memory, given a 2.5.41 kernel or better.
The -f switch displays the number of forks since boot. This includes the fork, vfork, and clone system calls, and is equivalent to the total number of tasks created. Each process is represented by one or more tasks, depending on thread usage. This display does not repeat.
The -m displays slabinfo.
The -n switch causes the header to be displayed only once rather than periodically.
The -s switch displays a table of various event counters and memory statistics. This display does not repeat.

delay is the delay between updates in seconds. If no delay is specified, only one report is printed with
the average values since boot.
count is the number of updates. If no count is specified and delay is defined, count defaults to infinity.

The -d reports disk statistics (2.5.70 or above required)
The -p followed by some partition name for detailed statistics (2.5.70 or above required)
The -S followed by k or K or m or M switches outputs between 1000, 1024, 1000000, or 1048576 bytes
The -V switch results in displaying version information.

FIELD DESCRIPTION FOR VM MODE

Procs

r: The number of processes waiting for run time << ready-to-run >>.
b: The number of processes in uninterruptible sleep << blocked >>.

Memory << (default) in kilobytes >>
swpd: the amount of virtual memory used.

free: the amount of idle memory.
buff: the amount of memory used as buffers.
cache: the amount of memory used as cache << page cache, not incl. swap cache>> .
inact: the amount of inactive memory. (-a option)
active: the amount of active memory. (-a option)

Swap << in kilobytes/second >>

si: Amount of memory swapped in from disk (/s).
so: Amount of memory swapped to disk (/s).

IO << in blocks/second >>

bi: Blocks received from a block device (blocks/s).
bo: Blocks sent to a block device (blocks/s).

System << ‘in’ and ‘cs’ are per second >>
in: The number of interrupts per second, including the clock.

cs: The number of context switches per second.

CPU These are percentages of total CPU time.
us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, shown as zero.

FIELD DESCRIPTION FOR DISK MODE 
   Reads 
       total: Total reads completed successfully
       merged: grouped reads (resulting in one I/O)
       sectors: Sectors read successfully
       ms: milliseconds spent reading 

   Writes 
       total: Total writes completed successfully
       merged: grouped writes (resulting in one I/O)
       sectors: Sectors written successfully
       ms: milliseconds spent writing 

   IO 
       cur: I/O in progress
       s: seconds spent for I/O 

FIELD DESCRIPTION FOR DISK PARTITION MODE 
       reads: Total number of reads issued to this partition
       read sectors: Total read sectors for partition
       writes : Total number of writes issued to this partition
       requested writes: Total number of write requests made for partition 

FIELD DESCRIPTION FOR SLAB MODE 
       cache: Cache name
       num: Number of currently active objects
       total: Total number of available objects
       size: Size of each object
       pages: Number of pages with at least one active object
       totpages: Total number of allocated pages
       pslab: Number of pages per slab

———————————————————-

ps

ps fields quick reference

The ‘usual’:

ps -Aef[ww]

ps aux[ww][f]
To print a process tree:

ps -ejH

ps axjf

Signal information:

ps s
To get info about threads:

ps -eLf
ps axH
ps axms

THREAD DISPLAY

H Show threads as if they were processes

-L Show threads, possibly with LWP and NLWP columns

-T Show threads, possibly with SPID column

m Show threads after processes

-m Show threads after processes
OTHER INFORMATION

L List all format specifiers.

-V Print the procps version.
The output from the ps au option is displayed in the following columns:

USER is the username for the running process.

PID is the process ID.

%CPU is the CPU utilization.

%MEM is the memory utilization.

VSZ is the virtual memory size.

RSS is the resident set sizethe number of kilobytes of program in memory.

TTY specifies which terminal the process was started from.

STAT is the process state.

START is the start time.

TIME is the execution time.

COMMAND is the command name.
PROCESS STATE CODES

Here are the different values that the s, stat and state output

specifiers (header “STAT” or “S”) will display to describe the state of

a process.

D Uninterruptible sleep (usually IO)

R Running or runnable (on run queue)

S Interruptible sleep (waiting for an event to complete)

T Stopped, either by a job control signal or because it is being

traced.

W paging (not valid since the 2.6.xx kernel)

X dead (should never be seen)

Z Defunct (“zombie”) process, terminated but not reaped by its

parent.
For BSD formats and when the stat keyword is used, additional

characters may be displayed:

< high-priority (not nice to other users)

N low-priority (nice to other users)

L has pages locked into memory (for real-time and custom IO)

s is a session leader

l is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)

+ is in the foreground process group

wchan WCHAN name of the kernel function in which the process is sleeping, a “-” if the process is running, or a “*” if the process is multi-threaded and ps is not displaying threads.

———————————————————-

/proc/meminfo fields quick reference

MemTotal Total usable RAM.

MemFree The sum of LowFree + HighFree.

Buffers Memory in the buffer cache.

Cached Memory in the page cache (doesn’t SwapCache).

SwapCached Memory that once was swapped out.

Active Memory that has been used more recently and usually is not reclaimed unless absolutely necessary.

Inactive Memory that has been less recently used.
HighTotal The total amount of memory in the high region. Highmem is all memory above (approximately) 860 MB of physical RAM.

HighFree High region free memory.

LowTotal The total amount of non-highmem memory.

LowFree The amount of free memory in the low memory region.

SwapTotal The total amount of swap memory.

SwapFree The total amount of free swap memory.

Dirty Memory waiting to get written back to the disk.

Writeback Memory that is actively being written back to the disk.

Mapped Files that have been mmapped.

Slab In-kernel data structures cache.

Committed_AS An estimate of how much RAM is needed to make a 99.99% guarantee that there is never an OOM (out of memory) for this workload. Normally the kernel overcommits memory. So if you do a 1 GB malloc, for example, nothing happens, really. Only when you start using that malloc memory do you get real memory on demand, and just as much as needed. Other cases might include when a file is mmapped that’s shared only when a write to the file occurs and a private copy of that data is created. Normally it is shared between processes. The Committed_AS is a guesstimate of how much RAM/swap is needed in the worst case.
PageTables The amount of memory dedicated to the lowest level of page tables.

VmallocTotal The total size of the vmalloc memory area.

VmallocUsed The amount of vmalloc area that is used.

VmallocChunk The largest contiguous block of vmalloc area that is free.
/proc/<pid>/tasks : threads of process <pid>

Hardware information

/proc/bus/*/devices

lspci

lsusb

lshw (Ubuntu specific?)

lshal (Ubuntu specific?)

lspcmcia

/sys

———————————————————-

top

top fields quick reference

A : toggles multiple windows display

Z : colour changes

1. COMMAND-LINE Options

The command-line syntax for top consists of:

-hv | -bcHisS -d delay -n iterations -p pid [,pid...]

The typically mandatory switches (‘-’) and even whitespace are completely optional.

-b : Batch mode operation

Starts top in ‘Batch mode’, which could be useful for sending output from top to other programs or to a file. In this

mode, top will not accept input and runs until the iterations limit you’ve set with the ‘-n’ command-line option or until killed.

-c : Command line/Program name toggle

Starts top with the last remembered ‘c’ state reversed. Thus, if top was displaying command lines, now that field will show program names, and visa versa. See the ‘c’ interactive command for additional information.

-d : Delay time interval as: -d ss.tt (seconds.tenths)

Specifies the delay between screen updates, and overrides the corresponding value in one’s personal configuration file or the startup default. Later this can be changed with the ‘d’ or ‘s’ interactive commands.

Fractional seconds are honored, but a negative number is not allowed. In all cases, however, such changes are prohibited if top is running in ‘Secure mode’, except for root (unless the ‘s’ command-line option was used). For additional information on ‘Secure mode’ see topic 5a. SYSTEM Configuration File.

-h : Help

Show library version and the usage prompt, then quit.

-H : Threads toggle

Starts top with the last remembered ‘H’ state reversed. When this toggle is On, all individual threads will be displayed. Otherwise, top displays a summation of all threads in a process.

-i : Idle Processes toggle

Starts top with the last remembered ‘i’ state reversed. When this toggle is Off, tasks that are idled or zombied will not be displayed.

-n : Number of iterations limit as: -n number

Specifies the maximum number of iterations, or frames, top should produce before ending.

-u : Monitor by user as: -u somebody

Monitor only processes with an effective UID or user name matching that given.
-U : Monitor by user as: -U somebody

Monitor only processes with a UID or user name matching that given. This matches real, effective, saved, and filesystem UIDs.

-p : Monitor PIDs as: -pN1 -pN2 … or -pN1, N2 [,...]

Monitor only processes with specified process IDs. This option can be given up to 20 times, or you can provide a comma delimited list with up to 20 pids. Co-mingling both approaches is permitted.

This is a command-line option only. And should you wish to return to normal operation, it is not necessary to quit and and restart top — just issue the ‘=’ interactive command.

-s : Secure mode operation

Starts top with secure mode forced, even for root. This mode is far better controlled through the system configuration file (see topic 5. FILES).

-S : Cumulative time mode toggle

Starts top with the last remembered ‘S’ state reversed. When ‘Cumulative mode’ is On, each process is listed with the cpu time that it and its dead children have used. See the ‘S’ interactive command for additional information regarding this mode.
-v : Version

Show library version and the usage prompt, then quit.

2. FIELDS / Columns

2a. DESCRIPTIONS of Fields

Listed below are top’s available fields. They are always associated with the letter shown, regardless of the position you may have established for them with the ‘o’ (Order fields) interactive command.

Any field is selectable as the sort field, and you control whether they are sorted high-to-low or low-to-high. For additional information on sort provisions see topic 3c. TASK Area Commands.

a: PID — Process Id

The task’s unique process ID, which periodically wraps, though never restarting at zero.

b: PPID — Parent Process Pid

The process ID of a task’s parent.

c: RUSER — Real User Name

The real user name of the task’s owner.

d: UID — User Id

The effective user ID of the task’s owner.

e: USER — User Name

The effective user name of the task’s owner.

f: GROUP — Group Name

The effective group name of the task’s owner.

g: TTY — Controlling Tty

The name of the controlling terminal. This is usually the device (serial port, pty, etc.) from which the process was started, and which it uses for input or output. However, a task need not be associated with a terminal, in which case you’ll see ‘?’ displayed.

h: PR — Priority

The priority of the task.

i: NI — Nice value

The nice value of the task. A negative nice value means higher priority, whereas a positive nice value means lower priority. Zero in this field simply means priority will not be adjusted in determining a task’s dispatchability.

j: P — Last used CPU (SMP)

A number representing the last used processor. In a true SMP environment this will likely change frequently since the kernel intentionally uses weak affinity. Also, the very act of running top may break this weak affinity and cause more processes to change CPUs more often (because of the extra demand for cpu time).

k: %CPU — CPU usage

The task’s share of the elapsed CPU time since the last screen update, expressed as a percentage of total CPU time. In a true SMP environment, if ‘Irix mode’ is Off, top will operate in ‘Solaris mode’ where a task’s cpu usage will be divided by the total number of CPUs. You toggle ‘Irix/Solaris’ modes with the ‘I’ interactive command.

l: TIME — CPU Time

Total CPU time the task has used since it started. When ‘Cumulative mode’ is On, each process is listed with the cpu time that it and its dead children has used. You toggle ‘Cumulative mode’ with ‘S’, which is a command-line option and an interactive command. See the ‘S’ interactive command for additional information regarding this mode.

m: TIME+ — CPU Time, hundredths

The same as ‘TIME’, but reflecting more granularity through hundredths of a second.

n: %MEM — Memory usage (RES)

A task’s currently used share of available physical memory.

o: VIRT — Virtual Image (kb)

The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.

VIRT = SWAP + RES.

p: SWAP — Swapped size (kb)

The swapped out portion of a task’s total virtual memory image.

q: RES — Resident size (kb)

The non-swapped physical memory a task has used.

RES = CODE + DATA.

r: CODE — Code size (kb)

The amount of physical memory devoted to executable code, also known as the ‘text resident set’ size or TRS.

s: DATA — Data+Stack size (kb)

The amount of physical memory devoted to other than executable code, also known as the ‘data resident set’ size or DRS.

t: SHR — Shared Mem size (kb)

The amount of shared memory used by a task. It simply reflects memory that could be potentially shared with other processes.

u: nFLT — Page Fault count

The number of major page faults that have occurred for a task. A page fault occurs when a process attempts to read from or write to a virtual page that is not currently present in its address space. A major page fault is when backing storage access (such as a disk) is involved in making that page available.

v: nDRT — Dirty Pages count

The number of pages that have been modified since they were last written to disk. Dirty pages must be written to disk before the corresponding physical memory location can be used for some other virtual page.

w: S — Process Status

The status of the task which can be one of:

‘D’ = uninterruptible sleep

‘R’ = running

‘S’ = sleeping

‘T’ = traced or stopped

‘Z’ = zombie

Tasks shown as running should be more properly thought of as ‘ready to run’ — their task_struct is simply represented on the Linux run-queue. Even without a true SMP machine, you may see numerous tasks in this state depending on top’s delay interval and nice value.

x: Command — Command line or Program name

Display the command line used to start a task or the name of the associated program. You toggle between command line and name with ‘c’, which is both a command-line option and an interactive command.

When you’ve chosen to display command lines, processes without a command line (like kernel threads) will be shown with only the program name in parentheses, as in this example: ( mdrecoveryd )

Either form of display is subject to potential truncation if it’s too long to fit in this field’s current width. That width depends upon other fields selected, their order and the current screen width.

Note: The ‘Command’ field/column is unique, in that it is not fixed-width. When displayed, this column will be allocated all remaining screen width (up to the maximum 512 characters) to provide for the potential growth of program names into command lines.

y: WCHAN — Sleeping in Function

Depending on the availability of the kernel link map (‘System.map’), this field will show the name or the address of the kernel function in which the task is currently sleeping. Running tasks will display a dash (‘-’) in this column.

Note: By displaying this field, top’s own working set will be increased by over 700Kb. Your only means of reducing that overhead will be to stop and restart top.

z: Flags — Task Flags

This column represents the task’s current scheduling flags which are expressed in hexadecimal notation and with zeros suppressed. These flags are officially documented in <linux/sched.h>. Less formal documentation can also be found on the ‘Fields select’ and ‘Order fields’ screens.

2b. SELECTING and ORDERING Columns

After pressing the interactive commands ‘f’ (Fields select) or ‘o’ (Order fields) you will be shown a screen containing the current fields string followed by names and descriptions for all fields.

Here is a sample fields string from one of top’s four windows/field groups and an explanation of the conventions used:

- Sample fields string:

ANOPQRSTUVXbcdefgjlmyzWHIK

- The order of displayed fields corresponds to the order of the letters in that string.

- If the letter is upper case the corresponding field itself will then be shown as part of the task display (screen width permitting). This will also be indicated by a leading asterisk (‘*’), as in this excerpt:

…

* K: %CPU = CPU usage

l: TIME = CPU Time

m: TIME+ = CPU Time, hundredths

* N: %MEM = Memory usage (RES)

* O: VIRT = Virtual Image (kb)

…

Fields select screen — the ‘f’ interactive command

You toggle the display of a field by simply pressing the corresponding letter.

Order fields screen — the ‘o’ interactive command

You move a field to the left by pressing the corresponding upper case letter and to the right with the lower case letter.

2c. CPU States

The CPU states are shown in the Summary Area. They are always shown as a percentage and are for the time between now and the last refresh.

us — User CPU time

The time the CPU has spent running users’ processes that are not niced.

sy — System CPU time

The time the CPU has spent running the kernel and its processes.

ni — Nice CPU time

The time the CPU has spent running users’ proccess that have been niced.

wa — iowait

Amount of time the CPU has been waiting for I/O to complete.

hi — Hardware IRQ

The amount of time the CPU has been servicing hardware interrupts.

si — Software Interrupts

The amount of time the CPU has been servicing software interrupts.

3. INTERACTIVE Commands

Listed below is a brief index of commands within categories. Some commands appear more than once — their meaning or scope may vary depending on the context in which they are issued.

3a. GLOBAL_Commands

<Ret/Sp> ?, =, A, B, d, G, h, I, k, q, r, s, W, Z

3b. SUMMARY_Area_Commands

l, m, t, 1

3c. TASK_Area_Commands

Appearance: b, x, y, z

Content: c, f, H, o, S, u

Size: #, i, n

Sorting: <, >, F, O, R

3d. COLOR_Mapping

<Ret>, a, B, b, H, M, q, S, T, w, z, 0 – 7

4b. COMMANDS_for_Windows

-, _, =, +, A, a, G, g, w

3a. GLOBAL Commands

The global interactive commands are always available in both full-screen mode and alternate-display mode. However, some of these interactive commands are not available when running in ‘Secure mode’.

If you wish to know in advance whether or not your top has been secured, simply ask for help and view the system summary on the second line.

<Enter> or <Space> :Refresh_Display

These commands do nothing, they are simply ignored. However, they will awaken top and following receipt of any input the entire display will be repainted.

Use either of these keys if you have a large delay interval and wish to see current status,

<?> or <h> :Help

There are two help levels available. The first will provide a reminder of all the basic interactive commands. If top is secured, that screen will be abbreviated.

Typing ‘h’ or ‘?’ on that help screen will take you to help for those interactive commands applicable to alternate-display mode.

<=> :Exit_Task_Limits
Removes restrictions on which tasks are shown.  This command will reverse any ‘i’ (idle tasks) and ‘n’ (max tasks) commands that might be active.  It also provides for an ‘exit’ from PID monitoring.  See the ‘-p’ command-line option  for a discussion of PID monitoring.
When operating in alternate-display mode this command has a slightly broader meaning.

<A> :Alternate_Display_Mode_toggle
This  command will switch between full-screen mode and alternate-display mode.  See topic
4 ALTERNATE-DISPLAY Mode and the ‘G’ interactive command for insight into ‘current’ windows and field groups.

<B> :Bold_Disable/Enable_toggle
This command will influence use of the ‘bold’ terminfo capability and alters both the summary area and  task  area  for the current’ window.  While it is intended primarily for use with dumb terminals, it can be applied anytime.
Note:  When  this  toggle is On and top is operating in monochrome mode, the entire display will appear as normal text.
Thus, unless the ‘x’ and/or ‘y’ toggles are using reverse for emphasis, there will be no visual confirmation that  they are even on.

* <d> or <s> :Change_Delay_Time_interval
You will be prompted to enter the delay time, in seconds, between display updates.
Fractional  seconds  are honored, but a negative number is not allowed.  Entering 0 causes (nearly) continuous updates, with an unsatisfactory display as the system and tty driver try to keep up with top’s  demands.   The  delay  value  is inversely proportional to system loading, so set it with care.
If  at  any time you wish to know the current delay time, simply ask for help and view the system summary on the second line.

<G> :Choose_Another_Window/Field_Group
You will be prompted to enter a number between 1 and 4 designating the window/field group  which  should  be  made  the current’  window.   You  will  soon  grow comfortable with these 4 windows, especially after experimenting with alternate-display mode.

<I> :Irix/Solaris_Mode_toggle
When operating in ‘Solaris mode’ (‘I’ toggled Off), a task’s cpu usage will be divided by the  total  number  of  CPUs. After issuing this command, you’ll be informed of the new state of this toggle.

<u> :select a user
You  will  be  prompted  for  a  UID or username. Only processes belonging to the selected user will be displayed. This option matches on the effective UID.

<U> :select a user
You will be prompted for a UID or username. Only processes belonging to the  selected  user  will  be  displayed.  This option matches on the real, effective, saved, and filesystem UID.

* <k> :Kill_a_task
You  will  be  prompted  for  a  PID  and  then the signal to send.  The default signal, as reflected in the prompt, is SIGTERM.  However, you can send any signal, via number or name.
If you wish to abort the kill process, do one of the following depending on your progress:
1) at the pid prompt, just press <Enter>
2) at the signal prompt, type 0

<q> :Quit

* <r> :Renice_a_Task
You will be prompted for a PID and then the value to nice it to.  Entering a positive value will  cause  a  process  to lose priority.  Conversely, a negative value will cause a process to be viewed more favorably by the kernel.

<W> :Write_the_Configuration_File
This  will  save all of your options and toggles plus the current display mode and delay time.  By issuing this command just before quitting top, you will be able restart later in exactly that same state.

<Z> :Change_Color_Mapping
This key will take you to a separate screen where you can change the colors for the ‘current’ window, or for  all  windows.  For details regarding this interactive command see topic 3d. COLOR Mapping.
*  The  commands  shown  with an asterisk (‘*’) are not available in ‘Secure mode’, nor will they be shown on the level-1 help screen.

3b. SUMMARY Area Commands
The summary area interactive commands are always available in both full-screen mode and alternate-display mode.   They  affect the beginning lines of your display and will determine the position of messages and prompts.

These  commands always impact just the ‘current’ window/field group.  See topic 4. ALTERNATE-DISPLAY Mode and the ‘G’ interactive command for insight into ‘current’ windows and field groups.
<l> :Toggle_Load_Average/Uptime  –  On/Off
This is also the line containing the program name (possibly an alias) when operating in full-screen mode or  the   current’ window name when operating in alternate-display mode.

<m> :Toggle_Memory/Swap_Usage  –  On/Off
This command affects two summary area lines.

<t> :Toggle_Task/Cpu_States  –  On/Off
This command affects from 2 to many summary area lines, depending on the state of the ’1′ toggle and whether or not top is running under true SMP.

<1> :Toggle_Single/Separate_Cpu_States  –  On/Off
This command affects how the ‘t’ command’s Cpu States portion is shown.  Although this toggle exists primarily to serve massively-parallel SMP machines, it is not restricted to solely SMP environments.

When  you see ‘Cpu(s):’ in the summary area, the ’1′ toggle is On and all cpu information is gathered in a single line. Otherwise, each cpu is displayed separately as: ‘Cpu0, Cpu1, …’

Note: If the entire summary area has been toggled Off for any window, you would be left with just the message line.   In  that way,  you  will  have  maximized  available task rows but (temporarily) sacrificed the program name in full-screen mode or the current’ window name when in alternate-display mode.

3c. TASK Area Commands
The task area interactive commands are always available in full-screen mode.

The task area interactive commands are never available in alternate-display mode if the ‘current’ window’s  task  display  has been toggled Off (see topic 4. ALTERNATE-DISPLAY Mode).

APPEARANCE of task window
The following commands will also be influenced by the state of the global ‘B’ (bold disable) toggle.

<b> :Bold/Reverse_toggle
This  command  will impact how the ‘x’ and ‘y’ toggles are displayed.  Further, it will only be available when at least one of those toggles is On.

<x> :Column_Highlight_toggle
Changes highlighting for the current sort field.  You probably don’t need a constant visual reminder of the sort  field and top hopes that you always run with ‘column highlight’ Off, due to the cost in path-length.
If you forget which field is being sorted this command can serve as a quick visual reminder.

<y> :Row_Highlight_toggle
Changes  highlighting  for “running” tasks.  For additional insight into this task state, see topic 2a DESCRIPTIONS of Fields, Process Status.

Use of this provision provides important insight into your system’s health.  The only costs will be  a  few  additional tty escape sequences.

<z> :Color/Monochrome_toggle
Switches  the  ‘current’  window  between your last used color scheme and the older form of black-on-white or white-on-black.  This command will alter both the summary area and task area but does not affect the state of the  ‘x’,  ‘y’  or ‘b’ toggles.

CONTENT of task window
<c> :Command_Line/Program_Name_toggle
This  command  will be honored whether or not the ‘Command’ column is currently visible.  Later, should that field come into view, the change you applied will be seen.

<f> and <o> :Fields_select or Order_fields
These keys display separate screens where you can change which fields are displayed and their  order.   For  additional information on these interactive commands see topic 2b. SELECTING and ORDERING Columns.

<S> :Cumulative_Time_Mode_toggle
When  this  toggle is On, all individual threads will be displayed.  Otherwise, top displays a summation of all threads in a process.

‘S’ :Cumulative_Time_Mode_toggle
When ‘Cumulative mode’ is On, each process is listed with the cpu time that it and its dead children have used.

When Off, programs that fork into many separate tasks will appear less demanding.  For programs like ‘init’ or a  shell this  is  appropriate  but  for others, like compilers, perhaps not.  Experiment with two task windows sharing the same sort field but with different ‘S’ states and see which representation you prefer.

After issuing this command, you’ll be informed of the new state of this toggle.  If you wish to know in advance whether or not ‘Cumulative mode’ is in effect, simply ask for help and view the window summary on the second line.

<u> :Show_Specific_User_Only
You will be prompted to enter the name of the user to display.  Thereafter, in that task window only matching User ID’s will be shown, or possibly no tasks will be shown. Later, if you wish to monitor all tasks again, re-issue this command but just press <Enter> at the prompt, without providing a name.

SIZE of task window
<i> :Idle_Processes_toggle
Displays all tasks or just active tasks.  When this toggle is Off, idled or zombied processes will not be displayed.

If  this  command  is applied to the last task display when in alternate-display mode, then it will not affect the window’s size, as all prior task displays will have already been painted.

<n> or <#> :Set_Maximum_Tasks
You will be prompted to enter the number of tasks to display.  The lessor of your number and available screen rows will be used.

When used in alternate-display mode, this is the command that gives you precise control over the size of each currently visible task display, except for the very last.  It will not affect the last  window’s size, as all prior task  displays will have already been painted.

Note: If you wish to increase the size of the last visible task display when in alternate-display mode, simply decrease the size of the task display(s) above it.

SORTING of task window
For compatibility, this top supports most of the former top sort keys.  Since this is primarily  a  service  to  former  top users, these commands do not appear on any help screen.
command   sorted field                  supported
A         start time (non-display)      No
M         %MEM                             Yes
N         PID                                    Yes
P         %CPU                                Yes
T         TIME+                               Yes

Before  using  any of the following sort provisions, top suggests that you temporarily turn on column highlighting using the ‘x’ interactive command.  That will help ensure that the actual sort environment matches your intent.

The following interactive commands will only be honored when the current sort field is visible.  The sort field might not be visible because:
1) there is insufficient Screen Width
2) the ‘f’ interactive command turned it Off

<<> :Move_Sort_Field_Left
Moves the sort column to the left unless the current sort field is the first field being displayed.

<>> :Move_Sort_Field_Right
Moves the sort column to the right unless the current sort field is the last field being displayed.

The following interactive commands will always be honored whether or not the current sort field is visible.

<F> or <O> :Select_Sort_Field
These keys display a separate screen where you can change which field is used as the sort column.

If  a  field is selected which was not previously being displayed, it will be forced On when you return to the top display.  However, depending upon your screen width and the order of your fields, this sort field may not be  displayable.

This  interactive command can be a convenient way to simply verify the current sort field, when running top with column highlighting turned Off.

<R> :Reverse/Normal_Sort_Field_toggle
Using this interactive command you can alternate between high-to-low and low-to-high sorts.

Note: Field sorting uses internal values, not those in column display.  Thus, the TTY and WCHAN fields will  violate  strict ASCII collating sequence.

3d. COLOR Mapping
When  you  issue the ‘Z’ interactive command, you will be presented with a separate screen.  That screen can be used to change the colors in just the current’ window or in all four windows before returning to the top display.

Available interactive commands
4 upper case letters to select a target
8 numbers to select a color
normal toggles available
‘B’       :bold disable/enable
‘b’       :running tasks “bold”/reverse
‘z’       :color/mono
other commands available
‘a’/'w’   :apply, then go to next/prior
<Enter>   :apply and exit
‘q’       :abandon current changes and exit

If your use ‘a’ or ‘w’ to cycle the targeted window, you will have applied the color scheme that was displayed when  you  left that  window.  You can, of course, easily return to any window and reapply different colors or turn colors Off completely with the ‘z’ toggle.

The Color Mapping screen can also be used to change the ‘current’ window/field group in  either  full-screen  mode  or  alternate-display  mode.   Whatever was targeted when ‘q’ or <Enter> was pressed will be made current as you return to the top display.

4. ALTERNATE-DISPLAY Mode
4a. WINDOWS Overview
Field Groups/Windows:
In full-screen mode there is a single window represented by the entire screen.  That single window can still be changed to display 1 of 4 different field groups (see the ‘G’ interactive command, repeated below).  Each of the 4 field groups has a unique separately configurable summary area and its own configurable task area.

In alternate-display mode, those 4 underlying field groups can now be made visible simultaneously, or can be turned Off individually at your command.

The summary area will always exist, even if it’s only the message line.  At any given time only one summary area can be displayed.  However, depending on your commands, there could be from zero to  four  separate  task  displays  currently showing on the screen.

Current Window:
The  current’  window is the window associated with the summary area and the window to which task related commands are always directed.  Since in alternate-display mode you  can  toggle  the  task  display  Off,  some  commands  might  be restricted for the current’ window.

A  further complication arises when you have toggled the first summary area line Off.  With the loss of the window name (the ‘l’ toggled line), you’ll not easily know what window is the ‘current’ window.

4b. COMMANDS for Windows
<-> and <_> :Show/Hide_Window(s)_toggles
The ‘-’ key turns the ‘current’ window’s task display On and Off.  When On, that task area will show a minimum  of  the columns  header  you’ve  established  with  the  ‘f’  and  ‘o’  commands.   It  will  also  reflect any other task area options/toggles you’ve applied yielding zero or more tasks.

The ‘_’ key does the same for all task displays.  In other words, it switches between the currently visible  task  display(s)  and  any  task display(s) you had toggled Off.  If all 4 task displays are currently visible, this interactive       command will leave the summary area as the only display element.

* <=> and <+> :Equalize_(re-balance)_Window(s)
The ‘=’ key forces the ‘current’ window’s task display to be visible.  It also reverses any ‘i’ (idle  tasks)  and  ‘n’ (max tasks) commands that might be active.

The ‘+’ key does the same for all windows.  The four task displays will reappear, evenly balanced.  They will also have retained any customizations you had previously applied, except for the ‘i’ (idle tasks) and ‘n’ (max tasks) commands.

* <A> :Alternate_Display_Mode_toggle
This command will switch between full-screen mode and alternate-display mode.

The first time you issue this command, all four task displays will be shown.  Thereafter when  you  switch  modes,  you will see only the task display(s) you’ve chosen to make visible.

* <a> and <w> :Next_Window_Forward/Backward
This will change the ‘current’ window, which in turn changes the window to which commands are directed.  These keys act in a circular fashion so you can reach any desired ‘current’ window using either key.

Assuming the window name is visible (you have not toggled ‘l’ Off), whenever the ‘current’ window name loses its emphasis/color, that’s a reminder the task display is Off and many commands will be restricted.

* <G> :Choose_Another_Window/Field_Group
You  will  be  prompted  to  enter a number between 1 and 4 designating the window/field group which should be made the current’ window.

In full-screen mode, this command is necessary to alter the ‘current’ window.  In alternate-display mode, it is  simply a less convenient alternative to the ‘a’ and ‘w’ commands.

<g> :Change_Window/Field_Group_Name
You will be prompted for a new name to be applied to the ‘current’ window.  It does not require that the window name be visible (the ‘l’ toggle to be On).

*  The interactive commands shown with an asterisk (‘*’) have use beyond alternate-display mode.
‘=’, ‘A’, ‘G’  are always available
‘a’, ‘w’       act the same when color mapping

5. FILES
5a. SYSTEM Configuration File
The presence of this file will influence which version of the ‘help’ screen is shown to an ordinary user.   More  importantly, it  will  limit  what ordinary users are allowed to do when top is running.  They will not be able to issue the following commands.
k         Kill a task
r         Renice a task
d or s    Change delay/sleep interval

The system configuration file is not created by top.  Rather, you create this file manually and place it in  the  /etc  directory.  Its name must be ‘toprc’ and must have no leading ‘.’ (period).  It must have only two lines.

Here is an example of the contents of /etc/toprc:
s         # line 1: ‘secure’ mode switch
5.0       # line 2: ‘delay’  interval in seconds

5b. PERSONAL Configuration File
This file is written as ‘$HOME/.your-name-4-top’ + ‘rc’.  Use the ‘W’ interactive command to create it or update it.

Here is the general layout:
global    # line 1: the program name/alias notation
“       # line 2: id,altscr,irixps,delay,curwin
per ea    # line a: winname,fieldscur
window    # line b: winflags,sortindx,maxtasks
“       # line c: summclr,msgsclr,headclr,taskclr

If  the $HOME variable is not present, top will try to write the personal configuration file to the current directory, subject to permissions.

6. STUPID TRICKS Sampler
Many of these ‘tricks’ work best when you give top a scheduling boost.  So plan on starting him with  a  nice  value  of  -10, assuming you’ve got the authority.

6a. Kernel Magic
For these stupid tricks, top needs full-screen mode.

-*-  The  user  interface,  through  prompts and help, intentionally implies that the delay interval is limited to tenths of a second.  However, you’re free to set any desired delay.  If you want to see Linux at his scheduling best, try a delay  of  .09 seconds or less.

For this experiment, under x-windows open an xterm and maximize it.  Then do the following:
. provide a scheduling boost and tiny delay via:
nice -n -10 top -d.09
. keep sorted column highlighting Off to minimize path length
. turn On reverse row highlighting for emphasis
. try various sort columns (TIME/MEM work well), and normal or reverse sorts to bring the
most active processes into view

What  you’ll  see  is a very busy Linux doing what he’s always done for you, but there was no program available to illustrate this.

-*-  Under an xterm using ‘white-on-black’ colors, try setting top’s task color to black and be sure that task highlighting is set to bold, not reverse.  Then set the delay interval to around .3 seconds.

After  bringing the most active processes into view, what you’ll see are the ghostly images of just the currently running tasks.

-*-  Delete the existing rcfile, or create a new symlink.  Start this new version then type ‘T’ (a secret key, see  topic  3c.
TASK Area Commands, Sorting) followed by ‘W’ and ‘q’.  Finally, restart the program with -d0 (zero delay).

Your display will be refreshed at three times the rate of the former top, a 300% speed advantage.  As top climbs the TIME ladder, be as patient as you can while speculating on whether or not top will ever reach the top.

6b. Bouncing Windows
For these stupid tricks, top needs alternate-display mode.

-*-  With 3 or 4 task displays visible, pick any window other than the last and turn idle processes Off.  Depending  on  where you applied ‘i’, sometimes several task displays are bouncing and sometimes it’s like an accordion, as top tries his best allocate space.

-*-  Set each window’s summary lines differently: one with no memory; another with no states; maybe one with nothing  at  all, just the message line.  Then hold down ‘a’ or ‘w’ and watch a variation on bouncing windows  –  hopping windows.

-*-  Display all 4 windows and for each, in turn, set idle processes to Off.  You’ve just entered the “extreme bounce” zone.

6c. The Big Bird Window
This stupid trick also requires alternate-display mode.

-*-  Display  all 4 windows and make sure that 1:Def is the ‘current’ window.  Then, keep increasing window size until the all the other task displays are “pushed out of the nest”.

When they’ve all been displaced, toggle between all visible/invisible windows.  Then ponder this:
is top fibbing or telling honestly your imposed truth?

—————————————————————

Take a look at LinuxDevice’s excellent report on the LF’s (Linux Foundation) Collabaration Summit held last week in SF, USA.

A quick sampling to whet your appetite:

• Intel hands over the Moblin project to the LF
• KVM’s being pushed as the way to go within Linux virtualization
• The Kernel Summit / Panel discussion was energetic, techy and interesting-
  • 2.6.29 kernel released two weeks back by LF
  • Andrew Morton bags the first-ever “Unsung Hero” award!
  • Intel and ATI will work towards greatly modernizing the kernel graphics stack
  • Ted Ts’o talks about moving to Oracle’s Btrfs filesystem
• LF announces the winning entries to the “We’re Linux” 1-minute video contest.

Read about all this (and more!)  here.