Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c

From: Terry Lambert (tlambert2_at_mindspring.com)
Date: 06/20/03

  • Next message: Terry Lambert: "Re: Meta: explain what where when? (was Re: userland accesstodevicesis moving!)" 
    Date: Thu, 19 Jun 2003 22:07:43 -0700
To: David Schultz <das@FreeBSD.ORG>

    David Schultz wrote:
    > As a side note, I also think it's important that the new
    > implementation have a clean separation between user data and FS
    > metadata, so that they are not in direct competition with each
    > other for memory.

    This was the rationale behind the original VM and buffer cache
    separation. Instead of coming from a limited system resource
    shared between the two, they came from a limited system resource
    shared between the two, and scavanged pages from each other and
    caused thrashing. This was especially obvious in programs that
    mmap'ed a lot of file data into memory (e.g. "ld"), and then by
    seeking around, thrashed all the code pages out of core.

    The net result of this approach is an HI disconnect when doing
    large compiles uin an X term, when all of X's pages are thrashed
    out, and you move the mose and the cursor does... nothing...
    for... a... very... long... time... -- not a good situation.

    > The present buffer cache may be too limited for
    > the massive number of dependencies softupdates needs to track for
    > FS-intensive loads, but we also don't want lots of accumulated dirty
    > buffers from heavy FS activity to force application data out of memory.

    This basically says that you need to stall dependency memory
    allocation at a high watermark, and force the update clock to
    tick until the problem is eliminated. The acceleration of the
    update clock that takes place today is insufficient for this:
    you need to force the tick, wait for the completion, and force
    the next tick, etc., until you get back to your low water mark.
    If you just accelerate the clock, the hysteresis will keep you
    in a constant state of thrashing.

    > The original buffer cache design is untenable largely because
    > Dyson wanted to maintain compatibility with existing FS
    > interfaces.

    At the time, the problem was that the vmobject_t's were not
    reference counted, and allowed to be aliased. This was more
    or less a debugging decision, which was made because there
    were a couple of places where the system created unintentional
    aliases for VM objects, and had some pretty severe crashes as
    a result. Once these were tracked down, intentional aliases
    would have been an acceptable approach. But instead, what
    happpened was that the buffer cache entry became married to the
    vnode structure, on a 1:1 basis, forever more. When the pager
    changed to assume this, then everyones fate was irevvocably
    sealed. 8-(.

    -- Terry
    _______________________________________________
    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: Terry Lambert: "Re: Meta: explain what where when? (was Re: userland accesstodevicesis moving!)"

    Relevant Pages

    • Re: Disk access speed question
      ... memory, generating various tokens that would be needed later, such ... processing unit, collates the data per processing unit, does one ... A similarily bad amount of thrashing would ... By comparison the sort/merge method only requires 2*N separate disk ...
      (comp.programming)
    • Re: Internal SQL Server Problem
      ... Obviously CPU speed did not create a "hard stop", but not sure that 2 cores actually create an additive speed, but the main point here is that this hardware is just not suitable for the job at hand. ... Cris Hanna [SBS - MVP] ... "In systems that use virtual memory, the resulting condition of a hard drive being used excessively for virtual memory because the physical memory is full. ... Disk thrashing considerably slows down the performance of a system because data has to be transferred back and forth from the hard drive to the physical memory. ...
      (microsoft.public.windows.server.sbs)
    • Re: Internal SQL Server Problem
      ... What you got away with in SBS 03 is no indication of what you can "get away with" in SBS 08 ... "In systems that use virtual memory, the resulting condition of a hard drive being used excessively for virtual memory because the physical memory is full. ... Disk thrashing considerably slows down the performance of a system because data has to be transferred back and forth from the hard drive to the physical memory. ... If you want this system to behave more appropriately, you need to seriously re-think your hardware specs. ...
      (microsoft.public.windows.server.sbs)
    • Re: wich is faster
      ... > image (both for PNG and JPEG). ... of that time out-of-process thrashing. ... eventually overflow hardware memory, and get swapped out. ... my question remains (unasked of the ImageMagick authors): ...
      (comp.programming)