Re: U Area Removal

From: Brian Fundakowski Feldman (green_at_FreeBSD.ORG)
Date: 11/11/04

  • Next message: Bruce M Simpson: "Re: U Area Removal"
    Date: Wed, 10 Nov 2004 22:16:39 -0500
    To: arch@FreeBSD.ORG
    
    

    On Wed, Nov 10, 2004 at 10:00:35PM -0500, David Schultz wrote:
    > Over the years, the amount of data we have stored in each process' U
    > area has eroded to the point where all we have left are the following:
    >
    > - A struct kinfo_proc that is only used for a.out core dumps.
    > This can be reconstructed at the time of the core dump, so
    > it doesn't need to be there.
    >
    > - The struct pstats for the process, which takes a mere 216 bytes
    > on i386.
    >
    > In exchange for the ability to swap out this 216-byte structure, we
    > keep around a 4096-byte page, a 132-byte vm_object, and a couple of
    > pointers. Moreover, there is a small amount of runtime overhead
    > associated with this, and developers need to remember to PHOLD() and
    > PRELE() the process as appropriate.[1]
    >
    > I propose to remove the ability to swap the U area, allocating p_stats
    > from malloced memory instead. Medium-term scheduling and swapping of
    > kernel stacks would be retained. Here are the patches; !i386 testers
    > wanted:
    >
    > http://www.freebsd.org/~das/patches/upages.diff
    >
    >
    > [1] Most of the instances of PHOLD() and PRELE() right now never
    > needed to be there or have been unnecessary ever since the PCB
    > was moved out of the U area.

    I am not going to get a chance to review this soon (which I'd like to)
    but I'm going to make sure I also voice support for removing this
    extra avenue for system instability due to media failure. I am happy
    to see you having the desire to take this step!

    -- 
    Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
      <> green@FreeBSD.org                               \  The Power to Serve! \
     Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\
    _______________________________________________
    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: Bruce M Simpson: "Re: U Area Removal"

    Relevant Pages

    • Re: Swap space
      ... > twice the amount of RAM if you need to capture a dump for debugging. ... > If you won't ever be doing that, you may not need so much swap. ... least the size of physical memory. ...
      (freebsd-questions)
    • Re: U Area Removal
      ... David Schultz wrote: ... the amount of data we have stored in each process' U ... > I propose to remove the ability to swap the U area, ...
      (freebsd-arch)
    • Re: U Area Removal
      ... the amount of data we have stored in each process' U ... > I propose to remove the ability to swap the U area, ... I'll try testing at least amd64 right now. ...
      (freebsd-arch)
    • U Area Removal
      ... the amount of data we have stored in each process' U ... - The struct pstats for the process, which takes a mere 216 bytes ... I propose to remove the ability to swap the U area, ...
      (freebsd-arch)
    • Re: swap volatile
      ... You have an active paging file with around 16GB of space. ... I was thinking that maybe 10GB of swap would be enough, ... The amount of paging space that you need ... amount of free RAM you have for buffer and cache space. ...
      (comp.unix.solaris)