Go to file
Andrey Vesnovaty bdfbe594a1 Expose max/min objs per slab and max slab size
By default maximal number of objects in slab can't exceed (16*2 - 1) and slab
size can't exceed 32M.
Today's high end servers having couple hundreds of RAM available for ARC may
run into a trouble with virtual memory because of the restriction mentioned
above.

Problem:
Reasons for very high number of virtual memory allocations:
	* Real slab size very small relative to the size of the entire RAM
	* Slabs allocated on virtual memory and fill entire ARC

The result is very high number of allocated virtual memory ranges (hundreds of
ranges). When virtual memory subsystem manages high number of ranges its
performance become so poor that it freezes from time to time.

Solution:
Number of objects per slab should be increased taking into account maximal
slab size which can also be increased if needed.

Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #337
2014-04-14 09:42:04 -07:00
cmd Refresh links to web site 2013-03-04 19:09:34 -08:00
config Linux 3.13 compat: Pass NULL for new delegated inode argument 2013-12-02 10:37:49 -08:00
include Add ddi_time_after and friends 2014-04-14 09:32:01 -07:00
lib Remove autotools products 2012-08-27 11:46:23 -07:00
man Remove incorrect use of EXTRA_DIST for man pages 2014-01-17 11:54:22 -08:00
module Expose max/min objs per slab and max slab size 2014-04-14 09:42:04 -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
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
COPYING Public Release Prep 2010-05-17 15:18:00 -07:00
DISCLAIMER Public Release Prep 2010-05-17 15:18:00 -07:00
Makefile.am build: do not call boilerplate ourself 2013-04-02 11:08:46 -07:00
META Tag spl-0.6.2 2013-08-16 15:17:35 -07:00
README.markdown Document how to run SPLAT 2013-10-09 13:52:59 -07:00
spl.release.in Move spl.release generation to configure step 2012-07-12 12:13:47 -07:00

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