OpenZFS on Linux and FreeBSD
Go to file
Brian Behlendorf a073aeb060 Add KMC_SLAB cache type
For small objects the Linux slab allocator has several advantages
over its counterpart in the SPL.  These include:

1) It is more memory-efficient and packs objects more tightly.
2) It is continually tuned to maximize performance.

Therefore it makes sense to layer the SPLs slab allocator on top
of the Linux slab allocator.  This allows us to leverage the
advantages above while preserving the Illumos semantics we depend
on.  However, there are some things we need to be careful of:

1) The Linux slab allocator was never designed to work well with
   large objects.  Because the SPL slab must still handle this use
   case a cut off limit was added to transition from Linux slab
   backed objects to kmem or vmem backed slabs.

   spl_kmem_cache_slab_limit - Objects less than or equal to this
   size in bytes will be backed by the Linux slab.  By default
   this value is zero which disables the Linux slab functionality.
   Reasonable values for this cut off limit are in the range of
   4096-16386 bytes.

   spl_kmem_cache_kmem_limit - Objects less than or equal to this
   size in bytes will be backed by a kmem slab.  Objects over this
   size will be vmem backed instead.  This value defaults to
   1/8 a page, or 512 bytes on an x86_64 architecture.

2) Be aware that using the Linux slab may inadvertently introduce
   new deadlocks.  Care has been taken previously to ensure that
   all allocations which occur in the write path use GFP_NOIO.
   However, there may be internal allocations performed in the
   Linux slab which do not honor these flags.  If this is the case
   a deadlock may occur.

The path forward is definitely to start relying on the Linux slab.
But for that to happen we need to start building confidence that
there aren't any unexpected surprises lurking for us.  And ideally
need to move completely away from using the SPLs slab for large
memory allocations.  This patch is a first step.

NOTES:
1) The KMC_NOMAGAZINE flag was leveraged to support the Linux slab
   backed caches but it is not supported for kmem/vmem backed caches.

2) Regardless of the spl_kmem_cache_*_limit settings a cache may
   be explicitly set to a given type by passed the KMC_KMEM,
   KMC_VMEM, or KMC_SLAB flags during cache creation.

3) The constructors, destructors, and reclaim callbacks are all
   functional and will be called regardless of the cache type.

4) KMC_SLAB caches will not appear in /proc/spl/kmem/slab due to
   the issues involved in presenting correct object accounting.
   Instead they will appear in /proc/slabinfo under the same names.

5) Several kmem SPLAT tests needed to be fixed because they relied
   incorrectly on internal kmem slab accounting.  With the updated
   test cases all the SPLAT tests pass as expected.

6) An autoconf test was added to ensure that the __GFP_COMP flag
   was correctly added to the default flags used when allocating
   a slab.  This is required to ensure all pages in higher order
   slabs are properly refcounted, see ae16ed9.

7) When using the SLUB allocator there is no need to attempt to
   set the __GFP_COMP flag.  This has been the default behavior
   for the SLUB since Linux 2.6.25.

8) When using the SLUB it may be desirable to set the slub_nomerge
   kernel parameter to prevent caches from being merged.

Original-patch-by: DHE <git@dehacked.net>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Prakash Surya <surya1@llnl.gov>
Signed-off-by: Tim Chase <tim@chase2k.com>
Signed-off-by: DHE <git@dehacked.net>
Signed-off-by: Chunwei Chen <tuxoko@gmail.com>
Closes #356
2014-05-22 10:28:01 -07:00
cmd Refresh links to web site 2013-03-04 19:09:34 -08:00
config Add KMC_SLAB cache type 2014-05-22 10:28:01 -07:00
include Add KMC_SLAB cache type 2014-05-22 10:28:01 -07:00
lib Remove autotools products 2012-08-27 11:46:23 -07:00
man Evenly distribute the taskq threads across available CPUs 2014-04-25 15:29:18 -07:00
module Add KMC_SLAB cache type 2014-05-22 10:28:01 -07:00
patches Reimplement rwlocks for Linux lock profiling/analysis. 2009-09-18 16:09:47 -07:00
rpm Document SPL module parameters. 2013-11-21 12:32:41 -08:00
scripts Add kmod repo integration 2013-08-01 10:27:34 -07:00
.gitignore Ignore *.{deb,rpm,tar.gz} files in the top directory. 2013-04-24 16:18:14 -07:00
AUTHORS Refresh AUTHORS 2012-12-19 09:40:18 -08:00
COPYING Public Release Prep 2010-05-17 15:18:00 -07:00
DISCLAIMER Public Release Prep 2010-05-17 15:18:00 -07:00
META Tag spl-0.6.2 2013-08-16 15:17:35 -07:00
Makefile.am build: do not call boilerplate ourself 2013-04-02 11:08:46 -07:00
README.markdown Document how to run SPLAT 2013-10-09 13:52:59 -07:00
autogen.sh build: do not call boilerplate ourself 2013-04-02 11:08:46 -07:00
configure.ac Document SPL module parameters. 2013-11-21 12:32:41 -08:00
copy-builtin Copy spl.release.in to kernel dir 2013-06-21 15:40:04 -07:00
spl.release.in Move spl.release generation to configure step 2012-07-12 12:13:47 -07:00

README.markdown

The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. This can be particularly useful when you want to track upstream Solaris development closely and do not want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives.

To build packages for your distribution:

$ ./configure
$ make pkg

If you are building directly from the git tree and not an officially released tarball you will need to generate the configure script. This can be done by executing the autogen.sh script after installing the GNU autotools for your distribution.

To copy the kernel code inside your kernel source tree for builtin compilation:

$ ./configure --enable-linux-builtin --with-linux=/usr/src/linux-...
$ ./copy-builtin /usr/src/linux-...

The SPL comes with an automated test suite called SPLAT. The test suite is implemented in two parts. There is a kernel module which contains the tests and a user space utility which controls which tests are run. To run the full test suite:

$ sudo insmod ./module/splat/splat.ko
$ sudo ./cmd/splat --all

Full documentation for building, configuring, testing, and using the SPL can be found at: http://zfsonlinux.org