> Hi, just wanted to chime in that I'm experiencing the same panic with > a fresh -CURRENT. I am also/still seeing the "kmem_map too small" panic on a tree cvsup:ed around April 27. I can consistently trigger it by doing "rsync -a /usr/ports /somepool/somepath", with both /usr and /somepool being on ZFS (different pools). This is on a machine with 1 GB memory, with the kmem size being 320 MB as per default. The kstat.zfs.misc.arcstats.size never jumps; the "solaris" memory usage never significantly jumps - stays between about 80 MB and 150 MB at all times. It does not even consistently increase in size within this range - it goes up and down. In terms of absolute sizes, nothing in the output of vmstat -m, except solaris, is even approaching the sizes we are talking about (everything is a handful of megs at most). Watching "top" during the rsync I can see wired memory steadily increasing. Starting at about 110 megs or so after startup (including parts of my desktop), it begins consistently increasing when I run the rsync. in this case I started to approach 200 megs. When rsync was done (ran it with -v this time) reading the source directory and began copying files, the growth of wired memory increased significantly in speed (it was up to 280 MB or so in under 30 seconds). Killing rsync did not cause the wired total to go down. Any suggestions on whether there is something else to monitor to find out what is using all the memory? zfs_kmem_alloc() always allocates with M_SOLARIS. kmem_cache_{create,alloc} don't, but they seem to be allocating very small amounts of memory (could there be leakage of a huge number of these?). Is it expected that ZFS would allocate significant amount of memory that is not categorized as M_SOLARIS? Could there be fragmentation going on? Are there very large allocations, relative to the 320 MB kmem size, intermixed with small allocations? Anything I can do in terms of testing that would help debug this, beyond what has already been done and reported on on -current? -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller_at_infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey_at_scode.org E-Mail: peter.schuller_at_infidyne.com Web: http://www.scode.org
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:09 UTC