[PATCH] sysctl cleanup - unifying sysctls: vm.kvm_size and vm.kvm_free

[mdf at FreeBSD.org]

On Mon, Jul 18, 2011 at 7:47 AM, Uffe Jakobsen <uffe at uffe.org> wrote:
> On 2011-07-18 15:54, mdf at FreeBSD.org wrote:
>> On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen<uffe at uffe.org>  wrote:
>>>
>>> Please consider this patch - it unifies sysctls: vm.kvm_size and
>>> vm.kvm_free.
>>>
>>> Currently these sysctls are only found under i386 and amd64:
>>>
>>> sys/i386/i386/pmap.c
>>> sys/i386/xen/pmap.c
>>> sys/amd64/amd64/pmap.c
>>>
>>> It seems logical (to me) to move them into a generic location suce as
>>> sys/vm/vm_kern.c
>>>
>>> Patch against HEAD (revision 224180) attached.
>>
>> I don't believe that VM_MAX_KERNEL_ADDRESS is relevant to all
>> architectures, which is why these sysctls are in i386/amd64 specific
>> files.
>>
>
> Well I'm not an expert - but I did some checking before submitting this
> patch.
>
> As far as I can see VM_MAX_KERNEL_ADDRESS is addressed in several generic
> kernel files:
>
> sys/kern/subr_param.c
> sys/vm/vm_map.c
> sys/vm/vm_object.c
>
> and as far as I can see these locations are not ifdef'ed with any platform
> specific condition.
>
>
>
> Further more the following platform-specific files defines
> VM_MAX_KERNEL_ADDRESS:
>
> sys/amd64/include/vmparam.h
> sys/arm/include/vmparam.h
> sys/i386/include/vmparam.h
> sys/ia64/include/vmparam.h
> sys/mips/include/vmparam.h
> sys/powerpc/include/vmparam.h
> sys/sparc64/include/vmparam.h
>
> That leaves us only with "pc98" and "x86" platform-specifics subdirs that
> does not directly define VM_MAX_KERNEL_ADDRESS
>
> sys/pc98/include/vmparam.h includes "i386/vmparam.h" which defines
> VM_MAX_KERNEL_ADDRESS
>
> While "x86" subdir is a little more questionable - though it has several
> includes for machine/vmparam.h which defines VM_MAX_KERNEL_ADDRESS
>
>
>
> Could soneone please give me an indication of what would be the correct way
> for me to verify this in a more "scientific" way.

Alan Cox is usually a definitive answer for FreeBSD vm questions.

My recollection was in the context of a bug with memguard(9) on
sparc64, however now that I refresh my memory the issue there was
VM_KMEM_SIZE_MAX, not VM_MAX_KERNEL_ADDRESS.

So, my apologies as my memory has led me astray.

Cheers,
matthew