Re: [zfs-discuss] mdb ::memstat including zfs buffer details?
> ZFS data buffers are attached to zvp; however, we still keep > metadata in the crashdump. At least right now, this means that > cached ZFS metadata has kvp as its vnode. > >Still, it's better than what you get currently. I absolutely agree. At one point, we discussed adding another vp for the metadata. IIRC, this was in the context of moving all of ZFS's allocations outside of the cage. There's no reason why you couldn't do the same to make counting of buffers more understandable, though. -j ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] mdb ::memstat including zfs buffer details?
On Nov 12, 2007 4:16 PM, <[EMAIL PROTECTED]> wrote: > >I don't think it should be too bad (for ::memstat), given that (at > >least in Nevada), all of the ZFS caching data belongs to the "zvp" > >vnode, instead of "kvp". > > ZFS data buffers are attached to zvp; however, we still keep metadata in > the crashdump. At least right now, this means that cached ZFS metadata > has kvp as its vnode. > > Still, it's better than what you get currently. Cheers, - jonathan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] mdb ::memstat including zfs buffer details?
>I don't think it should be too bad (for ::memstat), given that (at >least in Nevada), all of the ZFS caching data belongs to the "zvp" >vnode, instead of "kvp". ZFS data buffers are attached to zvp; however, we still keep metadata in the crashdump. At least right now, this means that cached ZFS metadata has kvp as its vnode. -j ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] mdb ::memstat including zfs buffer details?
On Nov 8, 2007 4:21 PM, Nathan Kroenert <[EMAIL PROTECTED]> wrote: > Hey all - > > Just a quick one... > > Is there any plan to update the mdb ::memstat dcmd to present ZFS > buffers as part of the summary? > > At present, we get something like: > > ::memstat > Page SummaryPagesMB %Tot > > Kernel 28859 112 13% > Anon34230 133 15% > Exec and libs 10305405% > Page cache 16876658% > Free (cachelist)26145 102 12% > Free (freelist)105176 410 47% > Balloon 0 00% > > Total 221591 865 > > Which just (as far as I can tell) includes the zfs buffers in Kernel > memory. > > And what I'd really like is: > > > ::memstat > Page SummaryPagesMB %Tot > > Kernel 28859 112 13% > Anon34230 133 15% > Exec and libs 10305405% > Page cache 16876658% > Free (cachelist)26145 102 12% > Free (zfscachelist) 1827346 1700 xx% > Free (freelist)105176 410 47% > Balloon 0 00% > > Total 221591 865 > > Which then represents the pages that *could* be freed up by ZFS in the > event that they are needed for other purposes... > > Any thoughts on this? Is there a great reason why we cannot do this? > > Also - Other utilities like vmstat, etc that print out memory... File an RFE. I don't think it should be too bad (for ::memstat), given that (at least in Nevada), all of the ZFS caching data belongs to the "zvp" vnode, instead of "kvp". The work that made that change was: 4894692 caching data in heap inflates crash dump Of course, this so-called "free" memory does act a bit differently than the cachelist, etc., so maybe it should be named slightly differently. Cheers, - jonathan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] mdb ::memstat including zfs buffer details?
I'm not aware of any plans to do this. If you're on S10U4 or NV, can use kstat to fetch arcstats on ZFS memory usage: kstat -n arcstats. Prior to the addition of arcstats, you needed to use mdb to determine how much memory ZFS was using... > Which just (as far as I can tell) includes the zfs buffers in Kernel memory. > That's correct. The ZFS ARC will show up in "Kernel". > Any thoughts on this? Is there a great reason why we cannot do this? > Anything is possible is software. It's a time and resources issue (as always - what do we not work on to get this done...) > Also - Other utilities like vmstat, etc that print out memory... > > Thoughts on those guys and the way they treat the ufs buffers versus the > zfs buffers? > I don't understand this part of your question Thanks, /jim > Cheers! > > Nathan. > > ___ > 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
[zfs-discuss] mdb ::memstat including zfs buffer details?
Hey all -
Just a quick one...
Is there any plan to update the mdb ::memstat dcmd to present ZFS
buffers as part of the summary?
At present, we get something like:
> ::memstat
Page SummaryPagesMB %Tot
Kernel 28859 112 13%
Anon34230 133 15%
Exec and libs 10305405%
Page cache 16876658%
Free (cachelist)26145 102 12%
Free (freelist)105176 410 47%
Balloon 0 00%
Total 221591 865
Which just (as far as I can tell) includes the zfs buffers in Kernel memory.
And what I'd really like is:
> ::memstat
Page SummaryPagesMB %Tot
Kernel 28859 112 13%
Anon34230 133 15%
Exec and libs 10305405%
Page cache 16876658%
Free (cachelist)26145 102 12%
Free (zfscachelist) 1827346 1700 xx%
Free (freelist)105176 410 47%
Balloon 0 00%
Total 221591 865
Which then represents the pages that *could* be freed up by ZFS in the
event that they are needed for other purposes...
Any thoughts on this? Is there a great reason why we cannot do this?
Also - Other utilities like vmstat, etc that print out memory...
Thoughts on those guys and the way they treat the ufs buffers versus the
zfs buffers?
Cheers!
Nathan.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
