On 15/11/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
> >> What's wrong with using "virtual memory" for these objects?
> >
> > I don't want to do this because in most cases, the HAL memory
> > entry that's labelled as VIRTMEM does *not* actually monitor
> > virtual memory.
> At this point in time, I still think it's the most simple change.
It may well be a simple change - but I think it's the wrong one.
In particular, it doesn't actually address the underlying issue.
On some systems, it's possible to retrieve virtual memory information.
On others, it's not. I would really like the HAL memory module to
reflect this honestly, and only report virtual memory information when
this is actually available.
But as far as the UCD memory statistics are concerned, we clearly
need to implement this based on *something*. Preferably something
consistent.
Given that most implementations already use {Real+Swap}Free,
this still seems the best choice to standardise on.
I do *not* want to shoehorn this into the HAL virtual memory entry, as
doing so would prevent us implementing this properly in the future.
However I am somewhat disappointed in the complete lack of interest
from anyone (other than Thomas) in this issue.
> As for Dave's patch, I'd still call for
> clarification in the MIB that we monitor "free" rather than
> "available" memory if that's what we do.
It depends on architecture :-)
I don't have the time at the moment to dig out my notes
on exactly how this information is retrieved on each system.
But I do remember that in some cases, it's reading a field
from a data structure that's explicitly called "available"
rather than "free".
Whether the O/S itself makes that distinction is another
matter, of course!
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
