Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Jun 2005 00:05:16 +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:  <200506110005.j5B05G1A008832@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
green       2005-06-11 00:05:16 UTC

  FreeBSD src repository

  Modified files:
    sys/vm               vm_contig.c 
  Log:
  The new contigmalloc(9) has a bad degenerate case where there were
  many regions checked again and again despite knowing the pages
  contained were not usable and only satisfied the alignment constraints
  This case was compounded, especially for large allocations, by the
  practice of looping from the top of memory so as to keep out of the
  important low-memory regions.  While the old contigmalloc(9) has the
  same problem, it is not as noticeable due to looping from the low
  memory to high.
  
  This degenerate case is fixed, as well as reversing the sense of the
  rest of the loops within it, to provide a tremendous speed increase.
  This makes the best case O(n * VM overhead) much more likely than the
  worst case O(4 * VM overhead).  For comparison, the worst case for old
  contigmalloc would be O(5 * VM overhead) in addition to its strategy
  of turning used memory into free being highly pessimal.
  
  Also, fix a bug that in practice most likely couldn't have been triggered,
  int the new contigmalloc(9): it walked backwards from the end of memory
  without accounting for how many pages it needed.  Potentially, nonexistant
  pages could have been mapped.  This hasn't occurred because the kernel
  generally requests as its first contigmalloc(9) a single page.
  
  Reported by: Nicolas Dehaine <nicko@stbernard.com>, wes
  MFC After: 1 month
  More testing by: Nicolas Dehaine <nicko@stbernard.com>, wes
  
  Revision  Changes    Path
  1.43      +23 -11    src/sys/vm/vm_contig.c



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