lkml.org 
[lkml]   [2009]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OOM killer in 2.6.31-rc2
Date
On Wednesday 08 July 2009, Wu Fengguang wrote:
>On Wed, Jul 08, 2009 at 01:15:15PM +0800, Wu Fengguang wrote:
>> On Tue, Jul 07, 2009 at 11:42:07PM -0400, Gene Heskett wrote:
[...]
>> I guess your near 800MB slab cache is somehow under scanned.
>
>Gene, can you run .31 with this patch? When OOM happens, it will tell
>us whether the majority slab pages are reclaimable. Another way to
>find things out is to run `slabtop` when your system is moderately loaded.

Its been running continuously, and after 24 hours is now showing:

Active / Total Objects (% used) : 578136 / 869737 (66.5%)
Active / Total Slabs (% used) : 35832 / 35836 (100.0%)
Active / Total Caches (% used) : 104 / 163 (63.8%)
Active / Total Size (% used) : 115103.39K / 135776.88K (84.8%)
Minimum / Average / Maximum Object : 0.01K / 0.16K / 4096.00K

OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
439989 179391 40% 0.05K 6567 67 26268K buffer_head
126237 126222 99% 0.13K 4353 29 17412K dentry
121296 121296 100% 0.48K 15162 8 60648K ext3_inode_cache
64779 47350 73% 0.28K 4983 13 19932K radix_tree_node
17158 16014 93% 0.08K 373 46 1492K vm_area_struct
14250 14250 100% 0.12K 475 30 1900K size-128
12600 12544 99% 0.04K 150 84 600K sysfs_dir_cache
11187 10813 96% 0.03K 99 113 396K size-32
9170 9170 100% 0.36K 917 10 3668K proc_inode_cache
8820 7560 85% 0.12K 294 30 1176K filp
8791 6107 69% 0.06K 149 59 596K size-64
6858 5532 80% 0.01K 27 254 108K anon_vma
3213 3157 98% 0.06K 51 63 204K
inotify_inode_mark_entry
2392 2319 96% 0.04K 26 92 104K Acpi-Operand
2020 778 38% 0.19K 101 20 404K skbuff_head_cache
1467 1442 98% 0.43K 163 9 652K shmem_inode_cache
1352 1212 89% 0.02K 8 169 32K Acpi-Namespace
1350 579 42% 0.12K 45 30 180K cred_jar
1288 1252 97% 0.50K 161 8 644K size-512
1121 1062 94% 0.06K 19 59 76K pid
998 990 99% 2.00K 499 2 1996K size-2048
780 665 85% 0.05K 10 78 40K ext3_xattr
702 653 93% 0.14K 27 26 108K idr_layer_cache
668 567 84% 1.00K 167 4 668K size-1024
650 547 84% 0.38K 65 10 260K sock_inode_cache
594 442 74% 0.44K 66 9 264K UNIX
585 474 81% 0.25K 39 15 156K size-256
560 526 93% 0.19K 28 20 112K size-192
555 272 49% 0.25K 37 15 148K ip_dst_cache
539 423 78% 0.34K 49 11 196K inode_cache
452 198 43% 0.03K 4 113 16K fs_cache

Is there anything unusual there?

>Thanks,
>Fengguang
>---
>From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>
>Subject: [PATCH] add per-zone statistics to show_free_areas()
>
>Currently, show_free_area() mainly display system memory usage. but it
>doesn't display per-zone memory usage information.
>
>However, if DMA zone OOM occur, Administrator definitely need to know
>per-zone memory usage information.
[...]
To Wu Fengguang, David H., Rafael W., lkml:

With this patch, the newest bios for this board, and without the
CONFIG_HIGHMEM64G in the config, 2.6.31-rc2 has achieved a full days uptime.
I did do a swapoff -a; swapon -a about an hour into the boot to zero the swap,
and in nearly 24 hours it hasn't used any. No oom's that I can find in the
logs.

If the 64G highmem option, and this bios meet on this machine, the crash is at
least 20 hours overdue. But it appears to be 100% normal yet.

My opinion is that the 64G, long address memory handling may be broken
somewhere. Running w/o it costs me about half a gig of ram, but in this case,
the loss is well worth it.

What is the reason that setting the 4G of memory option results in only
approximately 3.5G being shown again?

Many Thanks to all of you, I have a stable machine now.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

People are like onions -- you cut them up, and they make you cry.



\
 
 \ /
  Last update: 2009-07-09 17:45    [W:0.086 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site