sysctl for querying kmem_map->size

[Garrett Cooper]

On Thu, Sep 30, 2010 at 1:26 PM, Andriy Gapon <avg at icyb.net.ua> wrote:
> on 30/09/2010 21:52 Garrett Cooper said the following:
>> On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon <avg at icyb.net.ua> wrote:
>>>
>>> Here's a patch that adds a sysctl for querying kmem_map->size, which may be useful
>>> for system state/resources monitoring:
>>> http://people.freebsd.org/~avg/sysctl-kmem_map_size.diff
>>>
>>> I am quite unsure about sizeof(kmem_map->size) == sizeof(int) hack, but I couldn't
>>> think of other way to decide whether to use SYSCTL_ADD_UINT or SYSCTL_ADD_ULONG
>>> depending on real type behind vm_size_t.
>>
>>     Is the base value of the field size_t? If so, then it's ulong on
>> 64-bit archs and uint on 32-bit archs. Maybe it's a good time then to
>
> No, it's vm_size_t, but it's defined similarly to size_t I guess:
> vm_size_t -> __vm_size_t -> {__uint32_t or __uint64_t depending on arch}

    Well... that's basically size_t right? At first inspection it
seems silly to define it as __uint32_t or __uint64_t if it's really
the same thing (in theory) as __size_t . Of course the vmem folks
(like alc@) might have more context as to why things were done this
way.

>> actually get the sysctl and tunables work that I started on into base.
>> I have a functioning and tested copy of the tunables work, but I'll
>> need to do similar for the sysctls as well (des@ and I kind of got out
>> of sync a few months back).
>
> I believe that this is the first time I hear about this project.

    It wasn't an official project. It was more or less an email thread
that sort of turned into a challenge, which turned into a project :) :
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-08/msg00054.html
.
    As with all things though, I'm not a committer by any means, so
unless someone works with me to review and commit my code, it will
exist purely in the ether for all eternity. Part of the drawbacks of
being in GSoC purgatory.
Thanks!
-Garrett