Re: KTR changes

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 11/01/05

  • Next message: John Baldwin: "ether_ifdetach() races round 3(?)" 
    Date: Tue, 1 Nov 2005 21:55:49 +0000 (GMT)
To: Nate Lawson <nate@root.org>

    On Tue, 1 Nov 2005, Nate Lawson wrote:

    >>> These should be merged the following under KTR_MALLOC (KTR_MEM?):
    >>> KTR_UMA: uma_zalloc_arg, uma_zfree_arg
    >>> KTR_VM: vmspace_alloc, vmspace_free, vm_map_create, vm_map_entry_unlink
    >>
    >> Well, I'm not sure about those as the KTR_VM ones aren't related
    >> to kernel malloc at all. vmspaces are the user virtual address
    >> mappings with vm_map being individual mappings. :) That's like
    >> saying that mmap() should be part of malloc(). :) I also think
    >> KTR_UMA is probably useful for getting a general feel for memory
    >> allocation activity in the kernel.
    >
    > What I'm trying to achieve is a general "KTR_MEMORY_STUFF" key. If
    > you're interested in allocations, getting info about mappings wouldn't
    > hurt either.

    I'm not entirely sure I agree -- I think combining malloc and zone
    allocation makes sense, but I think keeping vm tracking separate also
    makes sense, as one tends not to be interested in both VM pieces and
    explicit kernel allocation simultaneously. Just like one probably doesn't
    want VFS events and device driver operations at the same time -- you can
    combine them, but since both at the same time tend not to be desirable...
    :-)

    Robert N M Watson
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: John Baldwin: "ether_ifdetach() races round 3(?)"

    Relevant Pages

    • [PPC64] Improved VSID allocation algorithm
      ... Replace the VSID allocation algorithm. ... These are distinguishable from kernel proto-VSIDs because the top bit ...
      (Linux-Kernel)
    • contributing to fbsd
      ... I'd like to contribute to kernel code. ... scheduling, smp, threading and resource allocation. ... Last time Linux kernel appeared to be more successfull ... and that fbsd slowly but confidently succeed in this direction. ...
      (freebsd-hackers)
    • Re: [PATCH] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)
      ... That's because a hotplug area (memory ... > may need to be limited to a single allocation type. ... back due to policy but the reclaim code things everything is just fine. ... > unreclaimable kernel memory as your patch does. ...
      (Linux-Kernel)
    • Re: contributing to fbsd
      ... > I'd like to contribute to kernel code. ... > scheduling, smp, threading and resource allocation. ... > and that fbsd slowly but confidently succeed in this direction. ...
      (freebsd-hackers)
    • Re: Big allocation AND per process memory!
      ... an allocation is in kernel space or user space. ... These types are confined to virtual memory ...
      (microsoft.public.development.device.drivers)