On 04 January, 2012 - Steve Gonczi sent me these 2,5K bytes: > The interesting bit is what happens inside arc_reclaim_needed(), > that is, how it arrives at the conclusion that there is memory pressure. > > Maybe we could trace arg0, which gives the location where > we have left the function. This would finger which return path > arc_reclaim_needed() took.
It's new code, basically comparing the inuse/total/free from kstat -n zfs_file_data, which seems buggered. > Steve > > > ----- Original Message ----- > > > > Well it looks like the only place this get's changed is in the > arc_reclaim_thread for opensolaris. I suppose you could dtrace it to see what > is going on and investigate what is happening to the return code of the > arc_reclaim_needed is. > > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c#2089 > > > > maybe > > > dtrace -n 'fbt:zfs:arc_reclaim_needed:return { trace(arg1) }' > > > Dave > > > > > /Tomas -- Tomas Forsman, st...@acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Umeå `- Sysadmin at {cs,acc}.umu.se _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
