VM balancing issues on 2.6.13: dentry cache not getting shrunk enough

I've been so, but I haven't time to get some until now.

I have a T40 laptop from time to time, dentry cache grows

slabinfo - version: 2.1 # name dentry_cache ext3_inode_cache  587635 589992

Leading to an impending

LowFree:          9268 kB

... and if I don't the system will to death, with exhaustion --- problems were supposed to be solved.

It turns out I formation of hugepages, reduction of memory caches and flushed:

echo 100 > echo 0 > /proc/sys/vm/nr_hugepages

The question is release dentry to a lack of low memory? does shrink the dentry cache:

dentry_cache ext3_inode_cache   17782  17784

LowFree:        835916 kB

Has anyone else

Thanks, regards,

- Ted

slabinfo - version: 2.1 # name nfs_write_data nfs_read_data nfs_inode_cache nfs_page rpc_buffers rpc_tasks rpc_inode_cache uhci_urb_priv fib6_nodes ip6_dst_cache ndisc_cache RAWv6 UDPv6 request_sock_TCPv6 TCPv6 ip_fib_alias ip_fib_hash UNIX tcp_tw_bucket tcp_bind_bucket inet_peer_cache secpath_cache xfrm_dst_cache ip_dst_cache arp_cache RAW UDP request_sock_TCP TCP flow_cache cfq_ioc_pool cfq_pool crq_pool deadline_drq as_arq mqueue_inode_cache hugetlbfs_inode_cache ext2_inode_cache ext2_xattr journal_handle journal_head revoke_table revoke_record ext3_inode_cache  587635 589992 ext3_xattr dnotify_cache eventpoll_pwq eventpoll_epi inotify_event_cache inotify_watch_cache kioctx kiocb fasync_cache shmem_inode_cache posix_timers_cache uid_cache blkdev_ioc blkdev_queue blkdev_requests biovec-(256) biovec-128 biovec-64 biovec-16 biovec-4 biovec-1 bio file_lock_cache sock_inode_cache skbuff_head_cache proc_inode_cache sigqueue radix_tree_node bdev_cache sysfs_dir_cache mnt_cache inode_cache dentry_cache filp names_cache key_jar idr_layer_cache buffer_head       153510 162891 mm_struct vm_area_struct fs_cache files_cache signal_cache sighand_cache task_struct anon_vma pgd size-131072(DMA) size-131072 size-65536(DMA) size-65536 size-32768(DMA) size-32768 size-16384(DMA) size-16384 size-8192(DMA) size-8192 size-4096(DMA) size-4096 size-2048(DMA) size-2048 size-1024(DMA) size-1024 size-512(DMA) size-512 size-256(DMA) size-256 size-192(DMA) size-192 size-128(DMA) size-128 size-64(DMA) size-64           150913 150914 size-32(DMA) size-32 kmem_cache

MemTotal:      2074880 kB MemFree:         15220 kB Buffers:        339900 kB Cached:         798368 kB SwapCached:      18252 kB Active:        1025436 kB Inactive:       603900 kB HighTotal:     1178944 kB HighFree:         5952 kB LowTotal:       895936 kB LowFree:          9268 kB SwapTotal:     2124352 kB SwapFree:      2060040 kB Dirty:            9356 kB Writeback:           0 kB Mapped:         691788 kB Slab:           405400 kB CommitLimit:   3161792 kB Committed_AS:  1206060 kB PageTables:       5276 kB VmallocTotal:   114680 kB VmallocUsed:     24256 kB VmallocChunk:    89588 kB HugePages_Total:     0 HugePages_Free:      0 Hugepagesize:     4096 kB

Attachment: Description: Binary data ead2.googlesyndication.com/pagead/js/adsbygoogle.js" type="c04ff9cfb5521a33f6ec9f97-text/javascript"> pub-3422782820843221" 521a33f6ec9f97-text/javascript"> window.adsbygoogle || []).push({}); [email protected], [email protected] VM balancing issues on 2.6.13: dentry cache not getting shrunk enough "Theodore Ts'o" <[email protected]> Sun, 11 Sep 2005 06:57:09 -0400 Theodore Ts'o <[email protected]>, [email protected], [email protected] [email protected] Mutt/1.5.10i addthis_default_style "> _preferred_1"> _preferred_2"> _preferred_3"> _preferred_4"> addthis_bubble_style"> src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"> ead2.googlesyndication.com/pagead/js/adsbygoogle.js" type="c04ff9cfb5521a33f6ec9f97-text/javascript"> pub-3422782820843221" 521a33f6ec9f97-text/javascript"> window.adsbygoogle || []).push({}); itemprop="articleBody"> noticing this for a while (probably since at least 2.6.11 or been keeping close attention), but I haven't had the proof that this was the cause, and to write it up (Pentium M processor) with 2 gigs of memory, and after the system has been up for a while, the huge, as does the ext3_inode_cache: <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> 434515 514112 136 29 1 : tunables 120 60 0 : slabdata 17728 17728 0 464 8 1 : tunables 54 27 0 : slabdata 73748 73749 0 shortage in low memory: take corrective measures, very shortly thereafter become unresponsive and will end up thrashing itself symptoms that are identical to a case of 2.4 lowmem except this is on a 2.6.13 kernel, where all of these can head off the system lockup by requesting the which will immediately cause a dramatic usage in both high- and low- memory as various /proc/sys/vm/nr_hugepages why isn't the kernel able to figure out how to do cache entries automatically when it starts thrashing due Clearly it can, since requesting hugepages 20097 20097 136 29 1 : tunables 120 60 0 : slabdata 693 693 0 464 8 1 : tunables 54 27 0 : slabdata 2223 2223 0 seen this, or have some ideas about how to fix it? <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> 36 36 448 9 1 : tunables 54 27 0 : slabdata 4 4 0 32 36 448 9 1 : tunables 54 27 0 : slabdata 4 4 0 69 72 592 6 1 : tunables 54 27 0 : slabdata 12 12 0 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0 8 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0 8 9 448 9 1 : tunables 54 27 0 : slabdata 1 1 0 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0 7 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0 7 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0 1 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0 3 6 640 6 1 : tunables 54 27 0 : slabdata 1 1 0 2 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 12 14 1088 7 2 : tunables 24 12 0 : slabdata 2 2 0 11 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0 11 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0 343 350 384 10 1 : tunables 54 27 0 : slabdata 35 35 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 29 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0 29 45 256 15 1 : tunables 120 60 0 : slabdata 3 3 0 4 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0 2 9 448 9 1 : tunables 54 27 0 : slabdata 1 1 0 28 28 512 7 1 : tunables 54 27 0 : slabdata 4 4 0 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 144 148 960 4 1 : tunables 54 27 0 : slabdata 37 37 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 48 81 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 48 81 1 : tunables 120 60 0 : slabdata 0 0 0 65 130 60 65 1 : tunables 120 60 0 : slabdata 2 2 0 1 7 512 7 1 : tunables 54 27 0 : slabdata 1 1 0 1 12 316 12 1 : tunables 54 27 0 : slabdata 1 1 0 0 0 444 9 1 : tunables 54 27 0 : slabdata 0 0 0 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0 8 185 20 185 1 : tunables 120 60 0 : slabdata 1 1 0 2985 3000 52 75 1 : tunables 120 60 0 : slabdata 40 40 0 6 290 12 290 1 : tunables 120 60 0 : slabdata 1 1 0 0 0 16 226 1 : tunables 120 60 0 : slabdata 0 0 0 464 8 1 : tunables 54 27 0 : slabdata 73748 73749 0 0 0 44 88 1 : tunables 120 60 0 : slabdata 0 0 0 5 185 20 185 1 : tunables 120 60 0 : slabdata 1 1 0 0 0 36 107 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 28 135 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 36 107 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 3 226 16 226 1 : tunables 120 60 0 : slabdata 1 1 0 963 963 408 9 1 : tunables 54 27 0 : slabdata 107 107 0 0 0 96 41 1 : tunables 120 60 0 : slabdata 0 0 0 10 61 64 61 1 : tunables 120 60 0 : slabdata 1 1 0 95 135 28 135 1 : tunables 120 60 0 : slabdata 1 1 0 25 30 380 10 1 : tunables 54 27 0 : slabdata 3 3 0 78 78 152 26 1 : tunables 120 60 0 : slabdata 3 3 0 256 256 3072 2 2 : tunables 24 12 0 : slabdata 128 128 0 256 260 1536 5 2 : tunables 24 12 0 : slabdata 52 52 0 256 260 768 5 1 : tunables 54 27 0 : slabdata 52 52 0 256 260 192 20 1 : tunables 120 60 0 : slabdata 13 13 0 258 305 64 61 1 : tunables 120 60 0 : slabdata 5 5 0 340 904 16 226 1 : tunables 120 60 0 : slabdata 4 4 0 374 465 128 31 1 : tunables 120 60 0 : slabdata 14 15 0 45 45 88 45 1 : tunables 120 60 0 : slabdata 1 1 0 570 570 384 10 1 : tunables 54 27 0 : slabdata 57 57 0 880 1160 192 20 1 : tunables 120 60 0 : slabdata 58 58 0 672 672 332 12 1 : tunables 54 27 0 : slabdata 56 56 0 75 108 148 27 1 : tunables 120 60 0 : slabdata 4 4 0 27827 29162 276 14 1 : tunables 54 27 0 : slabdata 2083 2083 0 7 9 448 9 1 : tunables 54 27 0 : slabdata 1 1 0 3540 3552 40 96 1 : tunables 120 60 0 : slabdata 37 37 0 28 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0 1251 1404 316 12 1 : tunables 54 27 0 : slabdata 117 117 0 434515 514112 136 29 1 : tunables 120 60 0 : slabdata 17728 17728 0 4500 4660 192 20 1 : tunables 120 60 0 : slabdata 233 233 0 7 7 4096 1 1 : tunables 24 12 0 : slabdata 7 7 0 20 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0 91 116 136 29 1 : tunables 120 60 0 : slabdata 4 4 0 48 81 1 : tunables 120 60 0 : slabdata 2011 2011 0 119 119 576 7 1 : tunables 54 27 0 : slabdata 17 17 0 8115 8640 88 45 1 : tunables 120 60 0 : slabdata 192 192 0 113 119 32 119 1 : tunables 120 60 0 : slabdata 1 1 0 114 117 448 9 1 : tunables 54 27 0 : slabdata 13 13 0 135 140 384 10 1 : tunables 54 27 0 : slabdata 14 14 0 132 135 1344 3 1 : tunables 24 12 0 : slabdata 45 45 0 150 153 1328 3 1 : tunables 24 12 0 : slabdata 51 51 0 3535 3663 8 407 1 : tunables 120 60 0 : slabdata 9 9 0 115 115 4096 1 1 : tunables 24 12 0 : slabdata 115 115 0 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 18 18 32768 1 8 : tunables 8 4 0 : slabdata 18 18 0 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 158 158 8192 1 2 : tunables 8 4 0 : slabdata 158 158 0 0 0 4096 1 1 : tunables 24 12 0 : slabdata 0 0 0 385 387 4096 1 1 : tunables 24 12 0 : slabdata 385 387 0 0 0 2048 2 1 : tunables 24 12 0 : slabdata 0 0 0 75 76 2048 2 1 : tunables 24 12 0 : slabdata 38 38 0 0 0 1024 4 1 : tunables 54 27 0 : slabdata 0 0 0 212 212 1024 4 1 : tunables 54 27 0 : slabdata 53 53 0 0 0 512 8 1 : tunables 54 27 0 : slabdata 0 0 0 375 456 512 8 1 : tunables 54 27 0 : slabdata 57 57 0 0 0 256 15 1 : tunables 120 60 0 : slabdata 0 0 0 645 750 256 15 1 : tunables 120 60 0 : slabdata 50 50 0 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0 100 100 192 20 1 : tunables 120 60 0 : slabdata 5 5 0 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0 4259 4557 128 31 1 : tunables 120 60 0 : slabdata 147 147 0 0 0 64 61 1 : tunables 120 60 0 : slabdata 0 0 0 64 61 1 : tunables 120 60 0 : slabdata 2474 2474 0 0 0 32 119 1 : tunables 120 60 0 : slabdata 0 0 0 3273 3332 32 119 1 : tunables 120 60 0 : slabdata 28 28 0 124 124 128 31 1 : tunables 120 60 0 : slabdata 4 4 0 >config.gz

Follow-Ups:
- Re: VM balancing issues on 2.6.13: dentry cache not getting shrunk enough
  - From: Dipankar Sarma <[email protected]>

Prev by Date: Re: [PATCH 2.6.13 10/20] aic94xx: aic94xx_reg.c Register access
Next by Date: Re: [GIT PATCH] Remove devfs from 2.6.13
Previous by thread: [PATCH - Resend] PNPACPI: only parse device that have CRS method
Next by thread: Re: VM balancing issues on 2.6.13: dentry cache not getting shrunk enough
Index(es):
- Date
- Thread

[Index of Archives] [Kernel Newbies] [Netfilter] [Bugtraq] [Photo] [Gimp] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Video 4 Linux] [Linux for the blind]