It's supposed to be 7111576: arc shrinks in the absence of memory pressure
currently in status "accepted" and an RPE escalation pending. -----Original Message----- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Tomas Forsman Sent: Donnerstag, 5. Januar 2012 10:35 To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] arc_no_grow is set to 1 and never set back to 0 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/comm > on/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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
