Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

root 4 0.0 0.0 0 0 ? S< 00:00 0:00 [events/0]

root 5 0.0 0.0 0 0 ? S< 00:00 0:00 [khelper]

root 10 0.0 0.0 0 0 ? S< 00:00 0:00 [kthread]

root 21 0.0 0.0 0 0 ? S< 00:00 0:00 [kblockd/0]

root 62 0.0 0.0 0 0 ? S 00:00 0:00 [pdflush]

root 63 0.0 0.0 0 0 ? S 00:00 0:00 [pdflush]

root 65 0.0 0.0 0 0 ? S< 00:00 0:00 [aio/0]

root 36 0.0 0.0 0 0 ? S 00:00 0:00 [kapmd]

root 64 0.0 0.0 0 0 ? S 00:00 0:00 [kswapd0]

root 617 0.0 0.0 0 0 ? S 00:00 0:00 [mtdblockd]

root 638 0.0 0.0 0 0 ? S 00:00 0:00 [rpciod]

bin 834 0.0 0.7 1568 444 ? Ss 00:00 0:00 /sbin/portmap

root 861 0.0 0.0 0 0 ? S 00:00 0:00 [lockd]

root 868 0.0 0.9 1488 596 ? Ss 00:00 0:00 /sbin/syslogd -r

root 876 0.0 0.7 1416 456 ? Ss 00:00 0:00 /sbin/klogd -x

root 884 0.0 1.1 1660 700 ? Ss 00:00 0:00 /usr/sbin/rpc.statd

root 896 0.0 0.9 1668 584 ? Ss 00:00 0:00 /usr/sbin/inetd

root 909 0.0 2.2 2412 1372 ? Ss+ 00:00 0:00 -bash

telnetd 953 0.3 1.1 1736 732 ? S 05:58 0:00 in.telnetd

root 954 0.2 2.1 2384 1348 pts/0 Ss 05:58 0:00 -bash

root 960 0.0 1.2 2312 772 pts/0 R+ 05:59 0:00 ps aux

This is but one of the many ways to view output data using ps. The columns are explained in the following text.

• The USER and process ID (PID) fields should be self-explanatory.

• The %CPU field expresses the percent of CPU utilization since the beginning of the process's lifetime; thus, CPU usage will virtually never add up to 100 percent.

• The %MEM field indicates the ratio of the process's resident memory footprint to the total available physical memory.

• The VSZ field is the virtual memory size of the process in kilobytes.

• RSS is resident set size and indicates the nonswapped physical memory that a process has used, also in kilobytes.

• TTY is the controlling terminal of the process.

Most of the processes in this example are not associated with a controlling terminal. The ps command that generated Listing 13-9 was issued from a Telnet session, which is indicated by the pts/0 terminal device.

The STAT field describes the state of the process at the time this snapshot was produced. Here, S means that the process is sleeping, waiting on an event of some type, often I/O. R means that the process is in a runnable state (that is, the scheduler is free to give it control of the CPU if nothing of a higher priority is waiting). The left bracket next to the state letter is an indication that this process has a higher priority.

The final column is the command name. Those listed in brackets are kernel threads. Many more symbols and options are available; refer to the man page for ps for complete details.

Whereas ps is a one-time snapshot of the current system, top takes periodic snapshots of the state of the system and its processes. Similar to ps, top has numerous command line and configuration options. It is interactive and can be reconfigured while operating to customize the display to your particular needs.

Entered without options, top displays all running processes in a fashion very similar to the ps aux command presented in Listing 13-9, updated every 3 seconds. Of course, this and many other aspects of top are user configurable. The first few lines of the top screen display system information, also updated every 3 seconds. This includes the system uptime, the number of users, information on the number of processes and their state, and much more.

Listing 13-10 shows top in its default configuration, resulting from executing top from the command line without parameters.

Listing 13-10. top

top - 06:23:14 up 6:23, 2 users, load average: 0.00, 0.00, 0.00

Tasks: 24 total, 1 running, 23 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.0% us, 0.3% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si

Mem: 62060k total, 17292k used, 44768k free, 0k buffers

Swap: 0k total, 0k used, 0k free, 11840k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

978 root 16 0 1924 952 780 R 0.3 1.5 0:01.22 top

1 root 16 0 1416 508 452 S 0.0 0.8 0:00.47 init

2 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0

3 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 desched/0

4 root -2 -5 0 0 0 S 0.0 0.0 0:00.00 events/0

5 root 10 -5 0 0 0 S 0.0 0.0 0:00.09 khelper

10 root 18 -5 0 0 0 S 0.0 0.0 0:00.00 kthread

21 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0

62 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush

63 root 15 0 0 0 0 S 0.0 0.0 0:00.00 pdflush

65 root 19 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0

36 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kapmd

64 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0

617 root 25 0 0 0 0 S 0.0 0.0 0:00.00 mtdblockd

638 root 15 0 0 0 0 S 0.0 0.0 0:00.34 rpciod

834 bin 15 0 1568 444 364 S 0.0 0.7 0:00.00 portmap

861 root 20 0 0 0 0 S 0.0 0.0 0:00.00 lockd

868 root 16 0 1488 596 504 S 0.0 1.0 0:00.11 syslogd

876 root 19 0 1416 456 396 S 0.0 0.7 0:00.00 klogd

884 root 18 0 1660 700 612 S 0.0 1.1 0:00.02 rpc.statd

896 root 16 0 1668 584 504 S 0.0 0.9 0:00.00 inetd

909 root 15 0 2412 1372 1092 S 0.0 2.2 0:00.34 bash

953 telnetd 16 0 1736 736 616 S 0.0 1.2 0:00.27 in.telnetd

954 root 15 0 2384 1348 1096 S 0.0 2.2 0:00.16 bash

The default columns from Listing 13-10 are the PID, the user, the process priority, the process nice value, the virtual memory used by the process, the resident memory footprint, the amount of shared memory used by the task, and other fields that are identical to those described in the previous ps example.

Space permits only a cursory introduction to these useful utilities. You are encouraged to spend an afternoon with the man pages for top and ps to explore the richness of their capabilities.

The mtrace package is a simple utility that analyzes and reports on calls to malloc(), realloc(), and free() in your application. It is easy to use and can potentially help spot trouble in your application. As with other userland tools we have been describing in this chapter, you must have the mtrace package configured and compiled for your architecture. mtrace is a malloc replacement library that is installed on your target. Your application enables it with a special function call. Your embedded Linux distribution should contain the mtrace package.

To demonstrate this utility, we created a simple program that creates dynamic data on a simple linked list. Each list item was dynamically generated, as was each data item we placed on the list. Listing 13-11 reproduces the simple list structure.

Listing 13-11. Simple Linear Linked List

struct blist_s {

struct blist_s *next;

char *data_item;

int item_size;

int index;

};

Each list item was dynamically created using malloc() as follows and subsequently placed at the end of the linked list:

struct blist_s *p = malloc(sizeof(struct blist_s));

Each variable-sized data item in the list was also dynamically generated and added to the list item before being placed at the end of the list. This way, every list item was created using two calls to malloc(), one for the list item itself, represented by struct blist_s just shown, and one for the variable data item. We then generated 10,000 records on the list containing variable string data, resulting in 20,000 calls to malloc().