Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Aug 2013 23:26:10 -0700
From:      John-Mark Gurney <jmg@funkthat.com>
To:        Ollivier Robert <roberto@FreeBSD.org>
Cc:        svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-stable-9@FreeBSD.org
Subject:   Re: svn commit: r254859 - stable/9/sys/geom/eli
Message-ID:  <20130826062610.GC29777@funkthat.com>
In-Reply-To: <201308251429.r7PETlY7035520@svn.freebsd.org>
References:  <201308251429.r7PETlY7035520@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Ollivier Robert wrote this message on Sun, Aug 25, 2013 at 14:29 +0000:
> Author: roberto
> Date: Sun Aug 25 14:29:47 2013
> New Revision: 254859
> URL: http://svnweb.freebsd.org/changeset/base/254859
> 
> Log:
>   MFC r226840: AESNI-related commit, from a long time ago:
>   
>   Before this change when GELI detected hardware crypto acceleration it will
>   start only one worker thread. For software crypto it will start by default
>   N worker threads where N is the number of available CPUs.
>   
>   This is not optimal if hardware crypto is AES-NI, which uses CPU for AES
>   calculations.
>   
>   Change that to always start one worker thread for every available CPU.
>   Number of worker threads per GELI provider can be easly reduced with
>   kern.geom.eli.threads sysctl/tunable and even for software crypto it
>   should be reduced when using more providers.
>   
>   While here, when number of threads exceeds number of CPUs avilable don't
>   reduce this number, assume the user knows what he is doing.
>   
>   Submitted by:	Michael Moll <kvedulv@kvedulv.de>

I'll just point out that if you have a large number of geli volumes,
that this turns out to hurt performance rather than help it..  At
least in my testing on a 6 core machine w/ an 8 disk zfs pool where
all 8 disks are encrypted...

I think the problem is that we launch threads on a per geli/disk instead
of just having a generic set of threads that can work with any geli
volume...  When you have 17 geli volumes (like I do on my machine) * 6
threads, thats a lot of threads, imagine if the box had 32 or 64 cores?
You're looking at 500-1000 threads just for encryption...

In case someone asks, 8 zfs disks + 2 spares, swap, l2arc * 2, zil * 2
and zfs mirrored root all encrypted volumes...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



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