* [long]2.5.44-mm3 UP went into unexpected trashing
@ 2002-10-24 7:47 Helge Hafting
2002-10-24 7:58 ` Andrew Morton
0 siblings, 1 reply; 14+ messages in thread
From: Helge Hafting @ 2002-10-24 7:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
2.5.44-mm3 just began trashing. I ran debsums -s in order
to verify installed packages. This checksums all
binaries. Things got a little sluggish, but it finished.
Then I started a compile for 2.5.44-mm4, and the machine
became so hopeless that I stopped the compile. That
haven't happened before, I have 256M.
Looking at a running vmstat I saw lots of swapping,
almost no free memory (as usual) but _cache_
was down to 4004 too!
A top sorted by memory usage showed nothing out of
the ordinary, except that most processes were swapped
out. Slabinfo seemed to have lots of dentries though.
Attached files:
slabinfo contents of /proc/slabinfo at the time
topm screendump of top sorted by memory
vmstat1min output of vmstat with 1 minute interval
vmstat5min output of vmstat with 5 minute interval
I killed a few processes trying to write this
message, but the trashing came back after a little
while several times. So I had to reboot.
I am now running 2.5.44-mm2 with the same load
(compile+debsums) after 8 minutes there is 72k
in swap as usual, and cache fluctuating
around 120M, also as usual.
I'll try 2.5.44-mm4 when the compile finishes.
Helge Hafting
[-- Attachment #2: slabinfo --]
[-- Type: text/plain, Size: 13264 bytes --]
slabinfo - version: 1.2 (statistics)
unix_sock 35 40 392 4 4 1 : 120 60 : 50 2395 36 32 0 0 130 : 3276 403 3644 0
ip_conntrack 12 12 312 1 1 1 : 120 60 : 192 29934 41 40 0 0 132 : 106460 1948 108400 0
ip_mrt_cache 0 0 84 0 0 1 : 248 124 : 0 0 0 0 0 0 294 : 0 0 0 0
tcp_tw_bucket 0 0 96 0 0 1 : 248 124 : 80 2708 34 34 0 0 288 : 647 142 789 0
tcp_bind_bucket 21 145 24 1 1 1 : 248 124 : 145 5602 1 0 0 0 393 : 1216 139 1334 0
tcp_open_request 0 0 64 0 0 1 : 248 124 : 59 1701 92 92 0 0 307 : 629 96 725 0
inet_peer_cache 1 78 48 1 1 1 : 248 124 : 17 64 2 1 0 0 326 : 0 4 3 0
ip_fib_hash 9 145 24 1 1 1 : 248 124 : 16 16 1 0 0 0 393 : 17 1 9 0
ip_dst_cache 83 154 180 7 7 1 : 248 124 : 220 58469 10 3 0 0 270 : 3871 3250 7038 0
arp_cache 3 28 136 1 1 1 : 248 124 : 19 272 1 0 0 0 276 : 3 17 17 0
raw4_sock 0 0 420 0 0 1 : 120 60 : 9 9 1 1 0 0 129 : 2 1 3 0
udp_sock 7 9 440 1 1 1 : 120 60 : 9 24 1 0 0 0 129 : 112 6 111 0
tcp_sock 28 36 864 4 4 2 : 120 60 : 81 155 10 6 0 0 129 : 164382 19 164374 0
blkdev_requests 1024 1044 132 36 36 1 : 248 124 : 1044 1044 36 0 0 0 277 : 987 37 0 0
ntfs_big_inode_cache 7 8 480 1 1 1 : 120 60 : 8 8 1 0 0 0 128 : 9 1 3 0
ntfs_inode_cache 0 0 176 0 0 1 : 248 124 : 0 0 0 0 0 0 270 : 0 0 0 0
ntfs_name_cache 0 0 512 0 0 1 : 120 60 : 0 0 0 0 0 0 128 : 0 0 0 0
ntfs_attr_ctx_cache 0 0 40 0 0 1 : 248 124 : 16 16 1 1 0 0 340 : 12 1 13 0
nfs_write_data 0 0 392 0 0 1 : 120 60 : 10 180 17 17 0 0 130 : 311 18 329 0
nfs_read_data 0 0 376 0 0 1 : 120 60 : 10 70 7 7 0 0 130 : 40 7 47 0
nfs_inode_cache 2 6 608 1 1 1 : 120 60 : 192 402 34 33 0 0 126 : 229 57 284 0
nfs_page 0 0 100 0 0 1 : 248 124 : 39 414 15 15 0 0 287 : 311 20 331 0
devfsd_event 0 0 28 0 0 1 : 248 124 : 16 368 23 23 0 0 374 : 437 23 460 0
isofs_inode_cache 0 0 328 0 0 1 : 120 60 : 0 0 0 0 0 0 132 : 0 0 0 0
fat_inode_cache 0 0 348 0 0 1 : 120 60 : 0 0 0 0 0 0 131 : 0 0 0 0
ext2_inode_cache 173 486 432 54 54 1 : 120 60 : 54135 553282 13148 71 0 13 129 : 590970 20920 602702 9015
ext2_xattr 0 0 52 0 0 1 : 248 124 : 0 0 0 0 0 0 320 : 0 0 0 0
kioctx 0 0 184 0 0 1 : 248 124 : 0 0 0 0 0 0 269 : 0 0 0 0
kiocb 0 0 168 0 0 1 : 248 124 : 0 0 0 0 0 0 271 : 0 0 0 0
dnotify_cache 0 0 28 0 0 1 : 248 124 : 0 0 0 0 0 0 374 : 0 0 0 0
file_lock_cache 74 74 104 2 2 1 : 248 124 : 74 8685 4 2 0 0 285 : 27925 525 28413 0
fasync_cache 2 145 24 1 1 1 : 248 124 : 16 16 1 0 0 0 393 : 1 1 0 0
biovec-BIO_MAX_PAGES 256 260 3072 52 52 4 : 54 27 : 260 260 52 0 0 0 59 : 204 52 0 0
biovec-128 256 260 1536 52 52 2 : 54 27 : 260 260 52 0 0 0 59 : 204 52 0 0
biovec-64 256 260 768 52 52 1 : 120 60 : 530 8121 843 755 0 13 125 : 13016 1583 14336 7
biovec-16 257 266 200 14 14 1 : 248 124 : 285 2801 32 18 0 0 267 : 20959 248 20951 0
biovec-4 257 268 56 4 4 1 : 248 124 : 335 4375 13 9 0 0 315 : 39663 287 39694 0
biovec-1 338 338 20 2 2 1 : 248 124 : 800 32375 17 14 0 1 417 : 304528 1126 305380 18
bio 295 295 64 5 5 1 : 248 124 : 708 34467 82 73 0 1 307 : 379346 1296 380374 12
shmem_inode_cache 10 18 408 2 2 1 : 120 60 : 36 453 10 8 0 0 129 : 292 76 358 0
uid_cache 3 113 32 1 1 1 : 248 124 : 19 96 1 0 0 0 361 : 2 6 5 0
deadline_drq 1024 1111 36 11 11 1 : 248 124 : 1111 1111 11 0 0 0 349 : 1012 12 0 0
sock_inode_cache 77 110 352 10 10 1 : 120 60 : 121 284 11 1 0 0 131 : 169071 23 169020 0
skbuff_head_cache 162 168 164 7 7 1 : 248 124 : 168 252 7 0 0 0 272 : 143 19 0 0
sock 4 12 328 1 1 1 : 120 60 : 12 44 1 0 0 0 132 : 11 6 13 0
proc_inode_cache 276 276 328 23 23 1 : 120 60 : 420 18498 131 56 0 8 132 : 367816 430 367683 295
sigqueue 28 28 140 1 1 1 : 248 124 : 28 106 5 4 0 0 276 : 758781 6 758784 0
radix_tree_node 971 1386 268 99 99 1 : 120 60 : 6930 24576 501 1 0 0 134 : 60663 1465 60989 224
cdev_cache 23 234 48 3 3 1 : 248 124 : 468 2019 9 4 0 0 326 : 1381 53 1409 2
bdev_cache 11 39 100 1 1 1 : 248 124 : 39 80 1 0 0 0 287 : 48 5 42 0
mnt_cache 23 56 68 1 1 1 : 248 124 : 37 55 1 0 0 0 304 : 14 10 1 0
inode_cache 342 480 312 40 40 1 : 120 60 : 1284 10257 174 30 0 7 132 : 4220 761 4617 22
dentry_cache 1174824 1174824 140 41958 41958 1 : 248 124 : 1174824 1174923 41958 0 0 0 276 : 1131352 43467 0 0
filp 898 899 124 29 29 1 : 248 124 : 899 1293 29 0 0 0 279 : 830 68 0 0
names_cache 8 8 4096 8 8 1 : 54 27 : 8 8 8 0 0 0 55 : 1714470 8 1714477 0
buffer_head 267 402 56 6 6 1 : 248 124 : 9112 47877 177 6 0 3 315 : 75335 879 75879 188
mm_struct 66 66 352 6 6 1 : 120 60 : 66 6352 30 24 0 0 131 : 4793 588 5324 0
vm_area_struct 1376 1400 76 28 28 1 : 248 124 : 1600 4524 35 3 0 1 298 : 471413 65 470195 19
fs_cache 57 84 44 1 1 1 : 248 124 : 84 8981 1 0 0 0 332 : 3213 533 3690 0
files_cache 56 63 424 7 7 1 : 120 60 : 63 6052 22 15 0 0 129 : 3173 573 3690 0
signal_act 63 63 1344 21 21 1 : 54 27 : 69 2750 156 135 0 0 57 : 3070 679 3688 0
task_struct 70 70 1568 14 14 2 : 54 27 : 75 3387 85 71 0 0 59 : 3112 642 3685 0
pte_chain 679 2944 40 32 32 1 : 248 124 : 9476 138232 264 18 0 3 340 : 200322 1613 200858 427
mm_chain 126 202 16 1 1 1 : 248 124 : 140 14468 504 503 0 0 450 : 20396 560 20956 0
size-131072(DMA) 0 0 131072 0 0 32 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-131072 0 0 131072 0 0 32 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-65536(DMA) 0 0 65536 0 0 16 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-65536 0 0 65536 0 0 16 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-32768(DMA) 0 0 32768 0 0 8 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-32768 1 1 32768 1 1 8 : 8 4 : 6 24 24 23 0 0 9 : 13 24 36 0
size-16384(DMA) 0 0 16384 0 0 4 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-16384 7 7 16384 7 7 4 : 8 4 : 13 253 211 204 0 0 9 : 11314 243 11550 0
size-8192(DMA) 0 0 8192 0 0 2 : 8 4 : 0 0 0 0 0 0 9 : 0 0 0 0
size-8192 1 1 8192 1 1 2 : 8 4 : 23 492 408 365 0 9 9 : 2668 455 3093 29
size-4096(DMA) 0 0 4096 0 0 1 : 54 27 : 0 0 0 0 0 0 55 : 0 0 0 0
size-4096 47 47 4096 47 47 1 : 54 27 : 90 3017 2769 2722 0 0 55 : 42798 2982 45733 0
size-2048(DMA) 0 0 2048 0 0 1 : 54 27 : 0 0 0 0 0 0 56 : 0 0 0 0
size-2048 63 78 2048 39 39 1 : 54 27 : 100 494 98 59 0 3 56 : 314914 132 315000 1
size-1024(DMA) 0 0 1024 0 0 1 : 120 60 : 0 0 0 0 0 0 124 : 0 0 0 0
size-1024 104 104 1024 26 26 1 : 120 60 : 176 15688 121 95 0 0 124 : 373630 2259 375788 0
size-512(DMA) 0 0 512 0 0 1 : 120 60 : 0 0 0 0 0 0 128 : 0 0 0 0
size-512 104 104 512 13 13 1 : 120 60 : 104 113 13 0 0 0 128 : 453681 33 453630 0
size-256(DMA) 0 0 264 0 0 1 : 120 60 : 0 0 0 0 0 0 135 : 0 0 0 0
size-256 150 150 264 10 10 1 : 120 60 : 150 156 10 0 0 0 135 : 767117 20 767079 0
size-192(DMA) 0 0 200 0 0 1 : 248 124 : 0 0 0 0 0 0 267 : 0 0 0 0
size-192 57 57 200 3 3 1 : 248 124 : 95 333 6 3 0 0 267 : 2691262 16 2691251 0
size-128(DMA) 0 0 136 0 0 1 : 248 124 : 0 0 0 0 0 0 276 : 0 0 0 0
size-128 50 56 136 2 2 1 : 248 124 : 84 175 3 1 0 0 276 : 180 29 159 0
size-96(DMA) 0 0 104 0 0 1 : 248 124 : 0 0 0 0 0 0 285 : 0 0 0 0
size-96 1532 1554 104 42 42 1 : 248 124 : 1554 1684 42 0 0 0 285 : 558417 285 557171 0
size-64(DMA) 0 0 72 0 0 1 : 248 124 : 0 0 0 0 0 0 301 : 0 0 0 0
size-64 3583 3604 72 68 68 1 : 248 124 : 3604 35058 72 4 0 0 301 : 135732 2100 134264 0
size-32(DMA) 0 0 40 0 0 1 : 248 124 : 0 0 0 0 0 0 340 : 0 0 0 0
size-32 115460 115460 40 1255 1255 1 : 248 124 : 115460 115514 1255 0 0 0 340 : 10506682 1377 10392640 53
kmem_cache 96 96 160 4 4 1 : 248 124 : 96 96 4 0 0 0 272 : 37 57 0 0
[-- Attachment #3: topm --]
[-- Type: text/plain, Size: 1165 bytes --]
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
2563 helgehaf 15 0 31640 1612 17152 D 3,4 0,6 0:28 netscape
2572 helgehaf 15 0 2028 352 1880 R 0,9 0,1 0:07 top
3716 helgehaf 15 0 2812 324 2444 S 0,0 0,1 0:00 rxvt
442 proxy 15 0 11552 292 2956 S 0,0 0,1 0:15 squid
3702 helgehaf 15 0 2788 272 2444 S 0,1 0,1 0:00 rxvt
929 helgehaf 15 0 2880 248 2444 S 0,0 0,0 0:00 rxvt
3717 helgehaf 15 0 2752 240 2384 S 0,0 0,0 0:00 bash
2565 helgehaf 15 0 2796 224 2444 S 0,0 0,0 0:00 rxvt
932 helgehaf 15 0 2840 196 2444 S 0,0 0,0 0:00 rxvt
3715 helgehaf 15 0 2332 156 2256 Z 0,0 0,0 0:00 sh <defunct>
2549 helgehaf 15 0 2804 152 2444 S 0,0 0,0 0:00 rxvt
32 root 15 0 1500 116 1360 S 0,0 0,0 0:00 devfsd
926 helgehaf 15 0 2800 112 2444 S 0,0 0,0 0:00 rxvt
931 helgehaf 15 0 1300 96 1248 S 0,0 0,0 0:04 vmstat
538 helgehaf 15 0 2200 92 2124 S 0,0 0,0 0:00 ssh-agent
934 helgehaf 15 0 1300 88 1248 S 0,0 0,0 0:22 vmstat
[-- Attachment #4: vmstat1min --]
[-- Type: text/plain, Size: 6992 bytes --]
2 0 0 5548 3724 5008 7400 0 24 563 24 1148 756 3 37 60
1 0 0 10836 3228 2896 6520 11 93 534 93 1135 724 3 36 61
1 0 0 14760 8100 1652 6680 3 67 256 76 1058 427 6 8 86
1 0 0 14760 7932 1676 6716 2 0 3 1 1007 237 0 0 100
0 0 0 14760 7764 1680 6732 1 0 1 0 1007 232 0 0 100
0 0 0 14760 7708 1692 6748 1 0 1 0 1013 232 0 0 100
0 0 0 14760 6648 1728 7456 3 0 15 0 1008 239 0 0 100
1 0 0 14712 7408 1724 7472 2 0 19 0 1010 240 2 1 97
1 0 0 14712 7352 1724 7488 1 0 1 0 1012 233 0 0 100
1 0 0 14712 7240 1728 7504 1 0 1 0 1010 231 0 0 100
1 0 0 14712 7184 1732 7520 1 0 1 0 1016 234 0 0 100
1 0 0 14712 7128 1732 7536 0 0 0 0 1012 233 0 0 100
1 0 0 14880 7436 1572 7360 1 3 9 3 1011 236 2 1 97
0 0 0 14880 7380 1572 7380 1 0 1 0 1007 233 0 0 100
0 0 0 14880 7268 1572 7396 0 0 1 0 1015 233 0 0 100
0 0 0 14880 7212 1572 7412 1 0 1 0 1016 233 0 0 100
0 0 0 14880 6764 1572 7660 2 0 6 0 1009 234 0 0 100
1 0 0 15144 7332 1560 7376 1 5 9 5 1010 236 2 0 97
0 0 0 15144 7332 1560 7392 0 0 0 0 1009 232 0 0 100
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 15144 7276 1560 7408 0 0 0 0 1007 232 0 0 100
1 0 0 15144 7164 1560 7424 0 0 1 0 1007 233 0 0 100
1 0 0 15144 7108 1560 7440 0 0 0 0 1008 231 0 0 100
1 0 0 15132 7680 1416 7208 1 0 9 0 1007 235 2 0 97
0 0 0 15132 7680 1416 7224 1 0 1 0 1008 233 0 0 100
0 0 0 15132 7568 1416 7240 0 0 1 0 1009 232 0 0 100
1 0 0 15132 7400 1416 7256 1 0 1 0 1006 233 0 0 100
1 0 0 15132 7064 1416 7500 1 0 5 0 1008 231 0 0 100
1 0 1 15520 7620 1304 7120 1 7 9 7 1007 236 2 0 97
1 0 0 15520 7620 1304 7136 1 0 1 0 1007 233 0 0 100
1 0 0 15520 7508 1304 7152 0 0 0 0 1007 234 0 0 100
1 0 1 15520 7452 1304 7168 0 0 0 0 1007 234 0 0 100
0 0 0 15520 7340 1304 7184 0 0 1 0 1009 235 0 0 100
1 0 0 15532 8308 1200 6700 1 1 9 1 1021 241 2 1 97
0 0 1 15532 8252 1200 6716 1 0 1 0 1007 236 0 0 100
1 0 0 15532 8140 1200 6732 1 0 1 0 1006 232 0 0 100
0 0 0 15532 8084 1200 6748 0 0 0 0 1007 231 0 0 100
1 0 0 15532 7692 1200 6988 1 0 5 0 1014 235 0 0 100
1 0 0 15532 7188 1200 7360 1 0 7 0 1008 236 2 0 97
1 0 0 15532 7188 1200 7376 1 0 1 0 1007 234 0 0 100
1 0 0 15532 7020 1200 7392 1 0 1 0 1007 232 0 0 100
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 15532 6964 1200 7400 0 0 0 0 1008 234 0 0 100
0 0 0 15532 6908 1200 7400 1 0 1 0 1007 233 0 0 100
1 0 0 15516 8044 960 6692 0 0 1 0 1008 233 2 1 97
0 0 0 15516 7988 960 6716 0 0 0 0 1006 232 0 0 100
1 0 0 15516 7932 960 6732 1 0 1 0 1007 233 0 0 100
1 0 0 15516 7764 960 6756 2 0 3 0 1008 233 0 0 100
1 0 0 15516 6084 976 7000 20 0 25 1 1007 235 0 0 100
1 0 0 15460 7384 900 6720 0 0 5 0 1009 235 2 0 97
1 0 0 15460 7384 912 6728 0 0 0 0 1010 233 0 0 100
1 0 0 15460 7384 912 6728 0 0 0 0 1010 233 0 0 100
1 0 0 15460 7328 912 6736 0 0 0 0 1006 232 0 0 100
1 0 0 15460 7216 912 6752 1 0 1 0 1008 231 0 0 100
2 0 0 17128 2452 104 8100 134 47 262 47 1038 314 8 1 91
1 0 0 26912 2504 168 10360 174 185 634 201 1114 718 31 5 65
0 0 0 27200 2600 192 10332 4 5 12 5 1024 417 5 1 94
2 0 0 27308 3328 184 10016 1 2 4 2 1011 348 3 1 96
0 0 0 28136 3136 192 10492 10 14 32 15 1014 293 2 1 98
0 0 1 30224 7632 148 9052 7 41 87 41 1031 363 4 1 94
0 0 0 30224 5504 220 9760 20 0 33 0 1018 290 1 1 98
1 0 0 30224 5224 236 9912 1 0 4 0 1014 297 2 1 97
2 0 1 31740 3292 516 9956 48 31 380 32 1061 460 11 2 87
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
3 0 0 33860 3432 640 9372 28 38 3069 39 1351 1509 45 23 32
1 0 1 37408 3264 2012 9188 85 70 3086 71 1299 1225 46 20 34
1 0 1 38172 2768 608 9304 33 16 2856 25 1378 1575 44 23 34
2 0 0 39332 2560 1132 8788 37 25 2931 33 1260 1170 41 18 42
1 0 1 39904 3272 516 7284 41 13 4555 31 1321 1348 55 20 25
1 0 1 41576 2936 752 6924 64 36 2898 37 1374 1550 44 23 33
1 1 1 44128 2728 876 7060 202 66 3063 70 1344 1378 50 25 25
1 2 1 37312 3124 72 4172 441 120 1895 125 1222 860 65 34 1
1 0 1 45376 2472 92 6964 503 224 1129 226 1143 655 66 21 12
1 0 1 46512 3096 200 7096 157 36 963 38 1093 541 10 5 85
0 0 0 43672 3532 284 7136 122 19 997 20 1113 607 9 5 87
1 0 1 44592 3588 132 6760 106 32 211 33 1058 462 6 3 91
1 0 0 44464 3352 180 6680 15 0 25 0 1057 584 7 2 91
1 0 0 44388 2596 196 6972 5 0 22 13 1064 622 7 2 90
1 1 1 44980 3224 84 6284 151 31 204 32 1064 519 5 3 92
0 1 1 50560 2840 76 4044 485 186 609 198 1135 611 68 14 18
1 0 1 51360 3488 176 5728 296 133 516 136 1114 551 11 10 79
1 0 0 51168 4192 480 5176 62 13 390 201 1071 608 22 17 61
1 1 1 53200 8920 120 3912 208 164 710 177 1159 637 20 12 68
3 5 2 54476 1836 72 4004 412 152 942 161 1184 623 72 21 7
1 0 1 53864 2504 164 4448 259 75 432 78 1095 463 7 5 88
[-- Attachment #5: vmstat5min --]
[-- Type: text/plain, Size: 6873 bytes --]
1 0 0 1632 7092 5020 80104 0 0 0 0 1007 235 0 0 99
0 0 0 1632 8056 5020 78824 0 0 0 0 1006 232 0 0 99
1 0 0 1632 7832 5020 78884 0 0 0 0 1008 232 0 0 99
0 0 0 1632 7496 5020 78884 0 0 0 0 1006 233 0 0 99
0 0 0 1632 7328 5020 78884 0 0 0 0 1006 235 0 0 99
1 0 0 1632 6992 5020 78884 0 0 0 0 1005 231 0 0 99
1 0 0 1632 8012 5020 77604 0 0 0 0 1007 230 1 0 99
1 0 0 1632 7564 5020 77736 0 0 0 0 1007 233 0 0 99
1 0 0 1632 7396 5020 77736 0 0 0 0 1005 235 0 0 99
1 0 0 1632 7060 5020 77736 0 0 0 0 1005 231 0 0 99
1 0 0 1632 8200 4952 76440 0 0 0 0 1007 232 0 0 99
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 1632 7636 4952 76720 0 0 1 0 1005 232 0 0 99
1 0 0 1632 7468 4952 76720 0 0 0 0 1005 231 0 0 99
1 0 1 1632 7132 4952 76720 0 0 0 0 1005 232 0 0 99
0 0 0 1632 8212 4808 75568 0 0 0 0 1005 232 0 0 99
1 0 0 1632 7404 4824 76028 0 0 2 0 1007 233 0 0 99
0 0 0 1632 7232 4824 76028 0 0 0 0 1005 235 0 0 99
0 0 0 1632 8028 4516 75184 0 0 0 0 1005 232 0 0 99
2 0 0 1632 7804 4516 75244 0 0 0 0 1007 231 0 0 99
0 0 0 1632 7468 4516 75244 0 0 0 0 1006 231 0 0 99
0 0 0 1632 7300 4516 75244 0 0 0 0 1007 231 0 0 99
0 0 0 1632 8036 4316 74332 0 0 0 0 1009 232 0 0 99
0 0 0 1632 7700 4316 74504 0 0 1 0 1006 232 0 0 99
1 0 0 1632 7364 4320 74508 0 0 0 0 1005 232 0 0 99
1 0 0 1632 7196 4324 74508 0 0 0 0 1005 232 0 0 99
0 0 0 1632 8104 4208 73348 0 0 0 0 1005 231 0 0 99
1 0 0 1632 7876 4212 73408 0 0 0 0 1007 232 0 0 99
1 0 0 1632 7484 4212 73408 0 0 0 0 1009 232 0 0 99
0 0 0 1632 7316 4212 73408 0 0 0 0 1008 230 1 0 99
0 0 0 1632 6980 4212 73408 0 0 0 0 1007 230 1 0 99
1 0 0 1632 8612 4208 71576 0 0 0 0 1005 233 0 0 99
1 0 0 1632 8216 4208 71712 0 0 0 0 1005 233 0 0 99
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 1632 8048 4208 71712 0 0 0 0 1007 231 0 0 99
0 0 0 1632 7712 4208 71712 0 0 0 0 1005 232 0 0 99
0 0 0 1632 7544 4208 71712 0 0 0 0 1006 232 0 0 99
1 0 1 1632 7208 4208 71716 0 0 0 0 1006 231 0 0 99
1 0 0 1632 8232 4144 70472 0 0 0 0 1005 232 0 0 99
0 0 0 1632 7784 4152 70608 0 0 0 0 1005 231 0 0 99
1 0 0 1632 7616 4152 70608 0 0 0 0 1007 231 0 0 99
1 0 0 1632 7224 4152 70608 0 0 0 0 1006 234 0 0 99
1 0 0 1632 7052 4152 70608 0 0 0 0 1005 233 0 0 99
0 0 0 1632 7868 3848 69776 0 0 0 0 1006 235 0 0 99
1 0 0 1632 7644 3848 69836 0 0 0 0 1007 232 0 0 99
0 0 0 1632 7308 3848 69836 0 0 0 0 1006 232 0 0 99
1 0 0 1632 7136 3848 69836 0 0 0 0 1007 232 0 0 99
0 0 0 1632 7936 3492 69032 0 0 0 0 1005 231 0 0 99
1 0 0 1632 7708 3492 69092 0 0 0 0 1006 231 0 0 99
0 0 0 1632 7372 3492 69096 0 0 0 0 1005 231 0 0 99
1 0 0 1632 7204 3492 69096 0 0 0 0 1005 234 0 0 99
0 0 0 1632 7964 3400 68076 0 0 0 0 1008 232 1 0 99
1 0 1 1632 7736 3404 68136 0 0 0 0 1005 233 0 0 99
1 0 0 1632 7400 3404 68136 0 0 0 0 1006 231 0 0 99
0 0 1 1632 7232 3404 68136 0 0 0 0 1008 233 0 0 99
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 1632 8088 3312 67020 0 0 0 0 1005 235 0 0 99
1 0 0 1632 7808 3312 67124 0 0 0 0 1006 232 0 0 99
1 0 0 1632 7468 3312 67124 0 0 0 0 1007 232 0 0 99
1 0 0 1632 7300 3312 67124 0 0 0 0 1006 234 0 0 99
1 0 0 1632 8100 3232 66024 0 0 0 0 1006 230 1 0 99
1 0 0 1632 7876 3232 66084 0 0 0 0 1006 231 0 0 99
1 0 0 1632 7536 3232 66088 0 0 0 0 1006 232 0 0 99
1 0 0 1632 7176 3248 66148 0 0 0 0 1007 233 0 0 99
2 0 0 2656 2984 5084 16120 0 3 325 29 1087 555 10 27 63
2 0 1 8600 3028 3416 7096 0 20 473 50 1113 651 8 27 66
1 0 0 14760 6704 1728 7448 4 22 99 24 1029 312 1 4 95
1 0 0 14712 7128 1732 7528 1 0 4 0 1011 234 0 0 99
0 0 0 14880 6820 1572 7652 1 1 3 1 1012 234 0 0 99
0 0 0 15144 7164 1560 7432 0 1 2 1 1008 233 0 0 99
1 0 0 15132 7064 1416 7492 1 0 3 0 1007 233 0 0 99
1 0 0 15520 7396 1304 7176 0 1 2 2 1007 234 0 0 99
0 0 0 15532 7748 1200 6980 1 0 3 0 1010 235 0 0 99
1 0 0 15532 6964 1200 7400 1 0 2 0 1008 234 0 0 99
1 0 0 15516 6196 972 6992 5 0 6 0 1007 233 0 0 99
1 0 0 15460 7272 912 6744 0 0 1 0 1008 233 0 0 99
0 0 1 28136 3472 172 10340 64 51 188 54 1040 413 8 2 90
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
3 0 1 32704 3012 1040 9736 20 18 344 18 1049 416 6 2 92
1 0 1 40624 3568 788 6844 46 32 3275 39 1324 1367 46 21 33
1 0 1 43972 4104 188 6148 290 97 1964 100 1225 968 41 20 39
0 5 1 46240 2816 108 4584 102 25 157 29 1069 533 6 3 91
2 1 0 53952 3020 320 5880 285 131 634 175 1120 594 33 15 53
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 7:47 [long]2.5.44-mm3 UP went into unexpected trashing Helge Hafting
@ 2002-10-24 7:58 ` Andrew Morton
2002-10-24 8:17 ` Andrew Morton
0 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2002-10-24 7:58 UTC (permalink / raw)
To: Helge Hafting; +Cc: lkml
Helge Hafting wrote:
>
> 2.5.44-mm3 just began trashing. I ran debsums -s in order
> to verify installed packages. This checksums all
> binaries. Things got a little sluggish, but it finished.
>
> Then I started a compile for 2.5.44-mm4, and the machine
> became so hopeless that I stopped the compile. That
> haven't happened before, I have 256M.
>
> Looking at a running vmstat I saw lots of swapping,
> almost no free memory (as usual) but _cache_
> was down to 4004 too!
Memory leak.
> dentry_cache 1174824 1174824 140 41958 41958 1 : 248 124 : 1174824 1174923 41958 0 0 0 276 : 1131352 43467 0 0
160 megabytes of dcache.
Hopefully the rcu fix in -mm4 will cure this.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 7:58 ` Andrew Morton
@ 2002-10-24 8:17 ` Andrew Morton
2002-10-24 9:35 ` Dipankar Sarma
2002-10-24 11:45 ` Maneesh Soni
0 siblings, 2 replies; 14+ messages in thread
From: Andrew Morton @ 2002-10-24 8:17 UTC (permalink / raw)
To: Helge Hafting, lkml
Andrew Morton wrote:
>
> Hopefully the rcu fix in -mm4 will cure this.
Oh. It was in -mm3 too. But something went wrong with the
dcache shrinking there.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 8:17 ` Andrew Morton
@ 2002-10-24 9:35 ` Dipankar Sarma
2002-10-24 11:45 ` Maneesh Soni
1 sibling, 0 replies; 14+ messages in thread
From: Dipankar Sarma @ 2002-10-24 9:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: Helge Hafting, lkml
On Thu, Oct 24, 2002 at 08:22:07AM +0000, Andrew Morton wrote:
> Andrew Morton wrote:
> >
> > Hopefully the rcu fix in -mm4 will cure this.
>
> Oh. It was in -mm3 too. But something went wrong with the
> dcache shrinking there.
Hmm.. the thing to do here would be to look at cat /proc/sys/fs/dentry-state.
The number of dentries in the system should tally with dentry slab,
if it doesn't it might be an RCU issue in which case I would like to
look at /proc/rcu. If not, then we need to do some more digging.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 8:17 ` Andrew Morton
2002-10-24 9:35 ` Dipankar Sarma
@ 2002-10-24 11:45 ` Maneesh Soni
2002-10-24 11:47 ` Ed Tomlinson
1 sibling, 1 reply; 14+ messages in thread
From: Maneesh Soni @ 2002-10-24 11:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: Helge Hafting, lkml
On Thu, Oct 24, 2002 at 08:22:07AM +0000, Andrew Morton wrote:
> Andrew Morton wrote:
> >
> > Hopefully the rcu fix in -mm4 will cure this.
>
> Oh. It was in -mm3 too. But something went wrong with the
> dcache shrinking there.
Backing out larger-cpu-masks.patch fixes this in -mm3 so, -mm4 should not give
this problem. Basically callbacks are not getting processed due to incorrect
rcu_cpu_mask.
Maneesh
--
Maneesh Soni
IBM Linux Technology Center,
IBM India Software Lab, Bangalore.
Phone: +91-80-5044999 email: maneesh@in.ibm.com
http://lse.sourceforge.net/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 11:45 ` Maneesh Soni
@ 2002-10-24 11:47 ` Ed Tomlinson
2002-10-24 12:38 ` Dipankar Sarma
2002-10-24 12:46 ` Maneesh Soni
0 siblings, 2 replies; 14+ messages in thread
From: Ed Tomlinson @ 2002-10-24 11:47 UTC (permalink / raw)
To: maneesh, Dipankar Sarma, linux-kernel
Maneesh Soni wrote:
> On Thu, Oct 24, 2002 at 08:22:07AM +0000, Andrew Morton wrote:
>> Andrew Morton wrote:
>> >
>> > Hopefully the rcu fix in -mm4 will cure this.
>>
>> Oh. It was in -mm3 too. But something went wrong with the
>> dcache shrinking there.
>
> Backing out larger-cpu-masks.patch fixes this in -mm3 so, -mm4 should not
> give this problem. Basically callbacks are not getting processed due to
> incorrect rcu_cpu_mask.
Would this affect UP systems? Had the dentry leak on a UP box with 512m
memory. About 400m ended up in unfreeable dentries...
Ed Tomlinson
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 11:47 ` Ed Tomlinson
@ 2002-10-24 12:38 ` Dipankar Sarma
2002-10-24 15:31 ` Dipankar Sarma
2002-10-24 12:46 ` Maneesh Soni
1 sibling, 1 reply; 14+ messages in thread
From: Dipankar Sarma @ 2002-10-24 12:38 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: maneesh, linux-kernel, Rusty Russell
On Thu, Oct 24, 2002 at 12:01:31PM +0000, Ed Tomlinson wrote:
> Maneesh Soni wrote:
> >> Oh. It was in -mm3 too. But something went wrong with the
> >> dcache shrinking there.
> >
> > Backing out larger-cpu-masks.patch fixes this in -mm3 so, -mm4 should not
> > give this problem. Basically callbacks are not getting processed due to
> > incorrect rcu_cpu_mask.
>
> Would this affect UP systems? Had the dentry leak on a UP box with 512m
> memory. About 400m ended up in unfreeable dentries...
It does affect UP systems.
A quick look at /proc/rcu in a leaky system indicated that somehow
despite having a batch of RCUs, they are not getting started.
/* Fake initialization required by compiler */
@@ -106,10 +106,11 @@ static void rcu_start_batch(long newbatc
rcu_ctrlblk.maxbatch = newbatch;
}
if (rcu_batch_before(rcu_ctrlblk.maxbatch, rcu_ctrlblk.curbatch) ||
- (rcu_ctrlblk.rcu_cpu_mask != 0)) {
+ (find_first_bit(rcu_ctrlblk.rcu_cpu_mask, NR_CPUS) != NR_CPUS)) {
return;
}
- rcu_ctrlblk.rcu_cpu_mask = cpu_online_map;
+ memcpy(rcu_ctrlblk.rcu_cpu_mask, cpu_online_map,
+ sizeof(rcu_ctrlblk.rcu_cpu_mask));
}
Either find_first_bit() is not returning NR_CPUS when the bitmask has no
bit set or memcpy is not working on the UP version of cpu_online_map. Will
dig a little bit more.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 11:47 ` Ed Tomlinson
2002-10-24 12:38 ` Dipankar Sarma
@ 2002-10-24 12:46 ` Maneesh Soni
1 sibling, 0 replies; 14+ messages in thread
From: Maneesh Soni @ 2002-10-24 12:46 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Dipankar Sarma, linux-kernel, akpm
On Thu, Oct 24, 2002 at 07:47:39AM -0400, Ed Tomlinson wrote:
> Maneesh Soni wrote:
>
> > On Thu, Oct 24, 2002 at 08:22:07AM +0000, Andrew Morton wrote:
> >> Andrew Morton wrote:
> >> >
> >> > Hopefully the rcu fix in -mm4 will cure this.
> >>
> >> Oh. It was in -mm3 too. But something went wrong with the
> >> dcache shrinking there.
> >
> > Backing out larger-cpu-masks.patch fixes this in -mm3 so, -mm4 should not
> > give this problem. Basically callbacks are not getting processed due to
> > incorrect rcu_cpu_mask.
>
> Would this affect UP systems? Had the dentry leak on a UP box with 512m
> memory. About 400m ended up in unfreeable dentries...
Actually problem does not appear for SMP (with default NRCPUS) kernel as it getsproper rcu_cpu_mask and for UP it is not correct.
Maneesh
--
Maneesh Soni
IBM Linux Technology Center,
IBM India Software Lab, Bangalore.
Phone: +91-80-5044999 email: maneesh@in.ibm.com
http://lse.sourceforge.net/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 12:38 ` Dipankar Sarma
@ 2002-10-24 15:31 ` Dipankar Sarma
2002-10-24 15:46 ` Dipankar Sarma
0 siblings, 1 reply; 14+ messages in thread
From: Dipankar Sarma @ 2002-10-24 15:31 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: maneesh, linux-kernel, Rusty Russell, Andrew Morton
On Thu, Oct 24, 2002 at 06:08:09PM +0530, Dipankar Sarma wrote:
> On Thu, Oct 24, 2002 at 12:01:31PM +0000, Ed Tomlinson wrote:
> > Would this affect UP systems? Had the dentry leak on a UP box with 512m
> > memory. About 400m ended up in unfreeable dentries...
>
> It does affect UP systems.
>
> A quick look at /proc/rcu in a leaky system indicated that somehow
> despite having a batch of RCUs, they are not getting started.
>
> /* Fake initialization required by compiler */
> @@ -106,10 +106,11 @@ static void rcu_start_batch(long newbatc
> rcu_ctrlblk.maxbatch = newbatch;
> }
> if (rcu_batch_before(rcu_ctrlblk.maxbatch, rcu_ctrlblk.curbatch) ||
> - (rcu_ctrlblk.rcu_cpu_mask != 0)) {
> + (find_first_bit(rcu_ctrlblk.rcu_cpu_mask, NR_CPUS) != NR_CPUS)) {
> return;
> }
> - rcu_ctrlblk.rcu_cpu_mask = cpu_online_map;
> + memcpy(rcu_ctrlblk.rcu_cpu_mask, cpu_online_map,
> + sizeof(rcu_ctrlblk.rcu_cpu_mask));
> }
>
> Either find_first_bit() is not returning NR_CPUS when the bitmask has no
> bit set or memcpy is not working on the UP version of cpu_online_map. Will
> dig a little bit more.
OK, I think I know why this one didn't work.
If the bit_mask is 0, find_first_bit() returns 32 or BITS_PER_LONG.
That works fine as long as NR_CPUS is 32, but when it isn't things
are broken.
(find_first_bit(rcu_ctrlblk.rcu_cpu_mask, NR_CPUS) != BITS_PER_LONG)) {
return;
should probably work here.
I guess we need to audit all bitmask tests and fix them to check for
the right value.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 15:31 ` Dipankar Sarma
@ 2002-10-24 15:46 ` Dipankar Sarma
2002-10-24 23:35 ` Rusty Russell
0 siblings, 1 reply; 14+ messages in thread
From: Dipankar Sarma @ 2002-10-24 15:46 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: maneesh, linux-kernel, Rusty Russell, Andrew Morton
On Thu, Oct 24, 2002 at 09:01:05PM +0530, Dipankar Sarma wrote:
> OK, I think I know why this one didn't work.
>
> If the bit_mask is 0, find_first_bit() returns 32 or BITS_PER_LONG.
> That works fine as long as NR_CPUS is 32, but when it isn't things
> are broken.
>
> (find_first_bit(rcu_ctrlblk.rcu_cpu_mask, NR_CPUS) != BITS_PER_LONG)) {
> return;
>
> should probably work here.
>
> I guess we need to audit all bitmask tests and fix them to check for
> the right value.
Argh!! I spoke too soon.
AFAICS, find_first_bit() needs to be fixed to return "size" if the
bitmask is all zeros.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 15:46 ` Dipankar Sarma
@ 2002-10-24 23:35 ` Rusty Russell
2002-10-25 12:27 ` Dipankar Sarma
0 siblings, 1 reply; 14+ messages in thread
From: Rusty Russell @ 2002-10-24 23:35 UTC (permalink / raw)
To: dipankar; +Cc: maneesh, linux-kernel, Andrew Morton
In message <20021024211633.A21583@in.ibm.com> you write:
> AFAICS, find_first_bit() needs to be fixed to return "size" if the
> bitmask is all zeros.
Yes, the x86 one looks wrong. Other archs seem to get this correct.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-24 23:35 ` Rusty Russell
@ 2002-10-25 12:27 ` Dipankar Sarma
[not found] ` <3DB98823.67FDBEF3@digeo.com>
0 siblings, 1 reply; 14+ messages in thread
From: Dipankar Sarma @ 2002-10-25 12:27 UTC (permalink / raw)
To: Rusty Russell; +Cc: maneesh, linux-kernel, Andrew Morton
On Fri, Oct 25, 2002 at 09:35:17AM +1000, Rusty Russell wrote:
> In message <20021024211633.A21583@in.ibm.com> you write:
> > AFAICS, find_first_bit() needs to be fixed to return "size" if the
> > bitmask is all zeros.
>
> Yes, the x86 one looks wrong. Other archs seem to get this correct.
>
I tested this code in userspace and seems to do the right thing - return
"size" if no bit is set. But I can't find a larger_cpu_mask patch to
test with -mm5. Should I forward port the one from -mm4 experimental or
is there a new version available somewhere ?
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
bitops_fix.patch
----------------
diff -urN linux-2.5.44-mm5/include/asm-i386/bitops.h linux-2.5.44-mm5-fix/include/asm-i386/bitops.h
--- linux-2.5.44-mm5/include/asm-i386/bitops.h Sat Oct 19 09:32:01 2002
+++ linux-2.5.44-mm5-fix/include/asm-i386/bitops.h Fri Oct 25 15:19:54 2002
@@ -306,18 +306,23 @@
int res;
/* This looks at memory. Mark it volatile to tell gcc not to move it around */
- __asm__ __volatile__(
- "xorl %%eax,%%eax\n\t"
- "repe; scasl\n\t"
- "jz 1f\n\t"
- "leal -4(%%edi),%%edi\n\t"
- "bsfl (%%edi),%%eax\n"
- "1:\tsubl %%ebx,%%edi\n\t"
- "shll $3,%%edi\n\t"
- "addl %%edi,%%eax"
- :"=a" (res), "=&c" (d0), "=&D" (d1)
- :"1" ((size + 31) >> 5), "2" (addr), "b" (addr));
- return res;
+ __asm__ __volatile__(
+ "movl %%edi,%%esi\n\t"
+ "movl %%ecx,%%edx\n\t"
+ "repe; scasl\n\t"
+ "subl %%ecx,%%edx\n\t"
+ "movl %%edx,%%ecx\n\t"
+ "shll $5,%%edx\n\t"
+ "movl (%%esi,%%ecx,4),%%edi\n\t"
+ "movl %%ebx,%%eax\n\t"
+ "testl %%edi,%%edi\n\t"
+ "jz 1f\n\t"
+ "bsfl %%edi,%%eax\n\t"
+ "addl %%edx,%%eax\n\t"
+ "1:\t"
+ :"=a" (res), "=&c" (d0), "=&D" (d1)
+ :"1" ((size - 1) >> 5), "2" (addr), "b" (size));
+ return res;
}
/**
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
[not found] ` <20021025235222.A25786@in.ibm.com>
@ 2002-10-26 15:54 ` Dipankar Sarma
2002-10-29 12:53 ` Ed Tomlinson
0 siblings, 1 reply; 14+ messages in thread
From: Dipankar Sarma @ 2002-10-26 15:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Rusty Russell, maneesh, linux-kernel
Well, my earlier find_first_bit() implementation was completely bogus.
My sanity has now returned and I coded this patch below that fixes
find_find_bit() to return "size" if all bits are zero. I have tested it
extensively in userspace and it boots 2.5.44-mm5 which crashed with the earlier
version of the bitops_fix patch. I have coded the assembly routine
as optimal as I could think of and without introducing any new
branches or memory loads.
Along with this patch, I applied the larger_cpu_mask patch to -mm5
and sanity tested both UP and SMP kernels for dcache leaks in a 4CPU P3 box.
An ls -lR and subsequent unmounting of that filesystems showed that
the dentries were correctly getting returned the dcache slab and
that indicates that the larger_cpu_mask patch no longer breaks RCU.
I will do some more testing with this combination later with
rcu_stats applied on this tree (just to be sure), but so far it looks good.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
bitops_fix.patch
-----------------
diff -urN linux-2.5.44-mm5/include/asm-i386/bitops.h linux-2.5.44-mm5-fix/include/asm-i386/bitops.h
--- linux-2.5.44-mm5/include/asm-i386/bitops.h Sat Oct 19 09:32:01 2002
+++ linux-2.5.44-mm5-fix/include/asm-i386/bitops.h Sat Oct 26 17:52:09 2002
@@ -311,12 +311,13 @@
"repe; scasl\n\t"
"jz 1f\n\t"
"leal -4(%%edi),%%edi\n\t"
- "bsfl (%%edi),%%eax\n"
- "1:\tsubl %%ebx,%%edi\n\t"
+ "bsfl (%%edi),%%edx\n"
+ "subl %%ebx,%%edi\n\t"
"shll $3,%%edi\n\t"
- "addl %%edi,%%eax"
+ "addl %%edi,%%edx\n\t"
+ "1:\tmovl %%edx,%%eax\n\t"
:"=a" (res), "=&c" (d0), "=&D" (d1)
- :"1" ((size + 31) >> 5), "2" (addr), "b" (addr));
+ :"1" ((size + 31) >> 5), "2" (addr), "b" (addr), "d" (size));
return res;
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
2002-10-26 15:54 ` Dipankar Sarma
@ 2002-10-29 12:53 ` Ed Tomlinson
0 siblings, 0 replies; 14+ messages in thread
From: Ed Tomlinson @ 2002-10-29 12:53 UTC (permalink / raw)
To: dipankar, linux-kernel
Dipankar Sarma wrote:
> Well, my earlier find_first_bit() implementation was completely bogus.
> My sanity has now returned and I coded this patch below that fixes
> find_find_bit() to return "size" if all bits are zero. I have tested it
> extensively in userspace and it boots 2.5.44-mm5 which crashed with the
> earlier version of the bitops_fix patch. I have coded the assembly routine
> as optimal as I could think of and without introducing any new
> branches or memory loads.
>
> Along with this patch, I applied the larger_cpu_mask patch to -mm5
> and sanity tested both UP and SMP kernels for dcache leaks in a 4CPU P3
> box. An ls -lR and subsequent unmounting of that filesystems showed that
> the dentries were correctly getting returned the dcache slab and
> that indicates that the larger_cpu_mask patch no longer breaks RCU.
> I will do some more testing with this combination later with
> rcu_stats applied on this tree (just to be sure), but so far it looks
> good.
-mm5 with this patch is working fine here.
Thanks
Ed Tomlinson
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-10-29 12:51 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-24 7:47 [long]2.5.44-mm3 UP went into unexpected trashing Helge Hafting
2002-10-24 7:58 ` Andrew Morton
2002-10-24 8:17 ` Andrew Morton
2002-10-24 9:35 ` Dipankar Sarma
2002-10-24 11:45 ` Maneesh Soni
2002-10-24 11:47 ` Ed Tomlinson
2002-10-24 12:38 ` Dipankar Sarma
2002-10-24 15:31 ` Dipankar Sarma
2002-10-24 15:46 ` Dipankar Sarma
2002-10-24 23:35 ` Rusty Russell
2002-10-25 12:27 ` Dipankar Sarma
[not found] ` <3DB98823.67FDBEF3@digeo.com>
[not found] ` <20021025235222.A25786@in.ibm.com>
2002-10-26 15:54 ` Dipankar Sarma
2002-10-29 12:53 ` Ed Tomlinson
2002-10-24 12:46 ` Maneesh Soni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).