Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Mar 2013 12:47:45 +0000 (UTC)
From:      Alexander Motin <mav@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-projects@freebsd.org
Subject:   svn commit: r248878 - projects/camlock
Message-ID:  <201303291247.r2TClj3V086163@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: mav
Date: Fri Mar 29 12:47:45 2013
New Revision: 248878
URL: http://svnweb.freebsd.org/changeset/base/248878

Log:
  Add project branch to work on improving CAM performance and scalability.
  Such goals are planned within this project:
  
  1) Remove request allocation queue on the SIM level.  This supposed to
  simplify the code and reduce relations between device and transport/SIM.
  It will reduce effectiveness of bioq_disksort() in situations when several
  devices share single SIM, which queue is unable to fit all request allocated
  same time. But hopefully that is not a problem since SATA devices in most
  cases are not sharing queues, while SAS HBAs usually have large queues.
  Those people who need better scheduling can use to use more functional
  gsched.
  
  2) Remove multilevel queue freezing mechanism.  It was created to allow
  periph drivers to allocate more CCBs then device/SIM can handle in cases
  of error recovery.  After 1) succeed, it should not be a big problem to
  create another less complicated mechanism to handle overcommit.
  
  3) Remove per-SIM queue of allocated CCBs.  That will additionally reduce
  relations between device and SIM, while UMA should be able to handle memory
  no less effectively now.
  
  4) Try to split device locking into separate mutex(es).  It should reduce
  SIM lock contention, that is now the main limiting factor for CAM SMP
  scalability.  Hopefully after 1), 2) and 3) relations between device and
  SIM will be minimal, making this goal reachable.
  
  5) Hardware of some controllers, such as mps(4), allows to have several
  request/response queues. Using them should improve SMP scalability.
  Additional locking changes are required to do it, but hopefully it will
  be easier after 4).
  
  6) Success of 4) should also make reachable other following goals, such
  as CAM-level multipathing, etc.
  
  Discussed with:	gibbs
  Sponsored by:	iXsystems, Inc.

Added:
     - copied from r248877, head/
Directory Properties:
  projects/camlock/   (props changed)



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