Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jun 2004 01:02:00 +0000 (UTC)
From:      Brian Feldman <green@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/vm vm_contig.c
Message-ID:  <200406150102.i5F120XG078301@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
green       2004-06-15 01:02:00 UTC

  FreeBSD src repository

  Modified files:
    sys/vm               vm_contig.c 
  Log:
  Make contigmalloc() more reliable:
  
  1. Remove a race whereby contigmalloc() would deadlock against the
     running processes in the system if they kept reinstantiating
     the memory on the active and inactive page queues that it was
     trying to flush out.  The process doing the contigmalloc() would
     sit in "swwrt" forever and the swap pager would be going at full
     force, but never get anywhere.  Instead of doing it until the
     queues are empty, launder for as many iterations as there are
     pages in the queue.
  2. Do all laundering to swap synchronously; previously, the vnode
     laundering was synchronous and the swap laundering not.
  3. Increase the number of launder-or-allocate passes to three, from
     two, while failing without bothering to do all the laundering on
     the third pass if allocation was not possible.  This effectively
     gives exactly two chances to launder enough contiguous memory,
     helpful with high memory churn where a lot of memory from one pass
     to the next (and during a single laundering loop) becomes dirtied
     again.
  
  I can now reliably hot-plug hardware requiring a 256KB contigmalloc()
  without having the kldload/cbb ithread sit around failing to make
  progress, while running a busy X session.  Previously, it took killing
  X to get contigmalloc() to get further (that is, quiescing the system),
  and even then contigmalloc() returned failure.
  
  Revision  Changes    Path
  1.35      +25 -6     src/sys/vm/vm_contig.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406150102.i5F120XG078301>