How to stop the flushing of mmaped pages to disk in RHEL5.2 and later?

If your application is mmapping too much memory, resulting in lots of pdflush write activity and thereby by affecting system performance, vm.flush_mmap_pages kernel parameter could be useful.

/proc/sys/vm/flush_mmap_pages is introduced in RHEL5.2 kernel.

Setting /proc/sys/vm/flush_mmap_pages to 0 will stop the flushing of dirty memory-mapped file pages to disk as long as the memory map is active.

All dirty file pages will be asynchronously flushed to disk only as soon as the memory map is deactivated.

As per RHEL5.2 release notes.. (http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Release_Notes/x86/ar01s05.html)

Added a new kernel parameter: /proc/sys/vm/flush_mmap_pages. This parameter specifies whether or not memory-mapped file pages should be flushed to disk by kupdate while the memory map is active. Valid values for this parameter are 1 (enable memory mapping by kupdate) and 0 (disable memory mapping by kupdate). The default value for this parameter is 1.

To configure this parameter, use echo [1 or 0] /proc/sys/vm/flush_mmap_pages. Setting this parameter to 0 does the following:

kupdate will not flush dirty memory-mapped file pages as long as the memory map is active.

All dirty file pages will be asynchronously flushed to disk only as soon as the memory map is deactivated.

If you set /proc/sys/vm/flush_mmap_pages to 0, it is advisable that you use another application to manually sync memory-mapped pages to disk.

byobu - new funky wrapper for screen command

screen command was always been a very helpful tool for system admins.

byobu is a wrapper script over screen.

Best part is that it looks good.

You can also configure status notifications which will be displayed in the bottom screen. This is useful in monitoring the system while working in the terminal.

In Fedora, you can install byobu using following command.

# yum install byobu

Some useful shortcuts from man byobu

F2 - Create a new window

F3 - Move to previous window

F4 - Move to next window

F5 - Reload profile

F6 - Detach from this session

F7 - Enter copy/scrollback mode

F8 - Re-title a window

F9 - Configuration Menu

F12 - Lock this terminal

Run 'byobu' command to start the script.

How do you find out which cpu a process is running on?

The output of the ps command can be changed to a user defined format by using the -o option.

The following command can be used to display the CPU and the processes assigned.

# ps -eo pid,args,psr

Options:

pid - The process ID of the process.

args - Command with all its arguments as a string.

psr - processor currently assigned to the process.

Go to the man pages for more information on the ps command.

What is the logic behind killing processes during an Out of Memory situation?

As per kernel source code, following is OOM-killer logic,

A function called badness() is defined to calculate points for each processes.

* Points will be added to following processes.

Processes with high memory size.
Niced processes.

* Points will be reduced from following processes.

Processes which were running for long time.
Processes which were started by superusers.
Process with direct hardware access.

The process with the highest number of point, will be killed, unless it is already in the midst of freeing up memory on its own.

Then the system will wait for sometime to see if enough memory is freed. If enough memory is not freed after killing one process, the above steps will continue.

As per select_bad_process function, if a processes is having 0 or less points it could not be killed. The oom kills will be continued until there is no candidate processes left to kill. If the system is not able to find a candidate process to kill, it panics.

static unsigned long badness(struct task_struct *p, unsigned long uptime)
{
unsigned long points, cpu_time, run_time, s;

if (!p->mm)
return 0;

if (p->flags & PF_MEMDIE)
return 0;
/*
* The memory size of the process is the basis for the badness.
*/
points = p->mm->total_vm;

/*
* CPU time is in tens of seconds and run time is in thousands
* of seconds. There is no particular reason for this other than
* that it turned out to work very well in practice.
*/
cpu_time = (p->utime + p->stime) >> (SHIFT_HZ + 3);

if (uptime >= p->start_time.tv_sec)
run_time = (uptime - p->start_time.tv_sec) >> 10;
else
run_time = 0;

s = int_sqrt(cpu_time);
if (s)
points /= s;
s = int_sqrt(int_sqrt(run_time));
if (s)
points /= s;

/*
* Niced processes are most likely less important, so double
* their badness points.
*/
*/
if (task_nice(p) > 0)
points *= 2;

/*
* Superuser processes are usually more important, so we make it
* less likely that we kill those.
*/
if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_ADMIN) ||
p->uid == 0 || p->euid == 0)
points /= 4;

/*
* We don't want to kill a process with direct hardware access.
* Not only could that mess up the hardware, but usually users
* tend to only have this flag set on applications they think
* of as important.
*/
if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO))
points /= 4;
#ifdef DEBUG
printk(KERN_DEBUG "OOMkill: task %d (%s) got %d points\n",
p->pid, p->comm, points);
#endif
return points;
}

What is kipmi? Why is it taking too much cpu in my Red Hat Enterprise Linux system?

If your IPMI hardware interface does not support interrupts and is a KCS or SMIC interface, the IPMI driver will start a kernel thread for the interface to help speed things up. This is a low-priority kernel thread that constantly polls the IPMI driver while an IPMI operation is in progress.

kipmi is that low-priority kernel thread. If the system does large number of IPMI operations, there is a possibility of kipmi using too much cpu time.

The kipmi thread is a workaround to fix the hardware disability so there is no real fix. Sometimes firmware updates can fix this though.

As a workaround, you can disable kipmi using following steps. This may decrease the speed of IPMI operations though.
* Edit /etc/modprobe.conf and add following entry.

options ipmi_si force_kipmid=0

* Restart the ipmi using following command.

# service ipmi restart

skype and twitux

Tested Skype and Twitux in my Fedora 11 X86_64 system.

Used following repo for skype..

[skype]
name=Skype Repository
baseurl=http://download.skype.com/linux/repos/fedora/updates/i586/
enabled=1
gpgkey=http://www.skype.com/products/skype/linux/rpm-public-key.asc
gpgcheck=0

Twitux is a gnome client for twitter. Simple and nice..
http://sourceforge.net/projects/twitux/
http://twitter.com

tape tricks

* display contents of a tape

# tar tvf /dev/tape

* tape rewind

# mt -f /dev/tape rewind