(free shows:
total used free shared buffers cached
Mem: 256272 254224 2048 178004 63788 81448
-/+ buffers: 108988 147284
Swap: 103404 14952 88452
) and the profile is getting interesting. The top functions from
profile are:
001743b0 add_request 93 0.1802 2.42
0011ca58 filemap_nopage 96 0.1304 2.50
0015d2b4 ext2_find_entry 119 0.1662 3.10
00119c24 do_wp_page 126 0.2019 3.28
0015d250 ext2_match 165 1.6500 4.30
0019b5bc el3_rx 176 0.3212 4.59
00123604 get_empty_inode 256 0.7273 6.67
00124530 get_hash_table 339 1.9709 8.83
0015a3e0 ext2_check_dir_entry 379 2.1056 9.87
0019b0e0 el3_start_xmit 396 0.7857 10.32
Ignore the el3_* stuff. It's got a heavy ethernet load, and I'll put a
better card in there one of these days.
ext2_* is interesting, but I haven't looked at that yet.
get_hash_table() is interesting. It looks like all the time is being
chewed here in looking up buffers in the hash tables. That much time
being chewed implies that the hash isn't working too well, or the hash
chains are huge.
So: Is it safe to #define HASH_PAGES 16 and expect nothing to break,
and get_hash_table() to drop significantly in CPU time?
And what's the story with get_empty_inode()? why is this chewing so
much time??
[ for the record. The machine is running a busy httpd, innd, and a bit
of shell usage ].
Michael.