Re: VM wiring fixed

From: Alan Cox (alc_at_cs.rice.edu)
Date: 04/29/04

  • Next message: M. Warner Losh: "Re: hostap TX fix in 5.x" 
    Date: Wed, 28 Apr 2004 23:31:02 -0500
To: Brian Fundakowski Feldman <green@FreeBSD.org>

    On Wed, Apr 28, 2004 at 11:05:12PM -0400, Brian Fundakowski Feldman wrote:
    > Alan Cox <alc@cs.rice.edu> wrote:
    > > On Wed, Apr 28, 2004 at 08:08:17PM -0400, Brian Fundakowski Feldman wrote:
    > > > There are several severe wiring bugs in -CURRENT that I believe I have fixed.
    > > > Please test/review as appropriate if you're affected by any of them. This
    > > > is a superset of the previous patch which just mostly-fixed mlockall(2).
    > > >
    > > > * MAP_FUTUREWIRE was not unset in vmspace_dofree(), causing the next process
    > > > to use that vmspace to wire all of its memory.
    > >
    > > Would setting flags to 0 in vmspace_alloc() accomplish the same?
    >
    > Yeah, same deal, except since we're optimizing by only clearing/
    > reinitializing some fields for the vmspace-zone objects, it makes a little
    > more sense IMO to have it in the vmspace_dofree().
    >

    To be honest, I would prefer to see this done by initializing flags to
    zero in vmspace_alloc(). I don't see how setting a field to zero at
    allocation time is less efficient than calling

    static __inline void
    vm_map_modflags(vm_map_t map, vm_flags_t set, vm_flags_t clear)
    {
            map->flags = (map->flags | set) & ~clear;
    }

    at deallocation time. In fact, I would expect initializing the field
    to zero at initialization time to be faster. It is also the more
    conventional and conservative approach. (For example, it would
    protect us from a future change to UMA such that the pages used to
    fill a zone are no longer prezeroed.)

    I'll follow up on the other questions later. I would encourage you to
    go ahead and commit the fix to flags.

    Regards,
    Alan
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: M. Warner Losh: "Re: hostap TX fix in 5.x"

    Relevant Pages

    • Re: zero values on dynamic array
      ... One might as well wonder whether there is a compiler option to make the ... variables to zero, many compilers have that. ... Initializing dynamically allocated memory to zero is also plausible. ... But initializing out-of-bounds data to zero is not compiler dependent, ...
      (comp.lang.fortran)
    • Re: NULL pointer and zero value
      ... The former statement sets all bits of `p' to zero, ... necessarily a representation of the null pointer. ... > When initializing, instead of making a loop to assgin NULL to each ... > function member of struct ModuleFunction for each member of array, ...
      (comp.lang.c)
    • kobject must be initialized before calling kobject_init()?!
      ... structure you're supposed to be initializing -- if someone just ... kmallocs a struct kobject and passes it into this function, ... And also the code in kobject_initthat sets other fields to be zero ... documentation. ...
      (Linux-Kernel)
    • Re: early printk timings way off
      ... On Thu, 15 Sep 2005, Jesper Juhl wrote: ... > we not initializing this counter to zero? ... > first few messages) if things started out at zero and then actually ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)