Date: Thu, 10 Mar 2011 17:18:42 -0800
From: Andi Kleen <ak@linux.intel.com>
To: "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>, dm-crypt@saout.de,
        linux-kernel@vger.kernel.org, Milan Broz <mbroz@redhat.com>,
        Alasdair G Kergon <agk@redhat.com>
Subject: Re: dm-crypt: Performance Regression 2.6.37 -> 2.6.38-rc8
Message-ID: <20110311011842.GA5698@alboin.amr.corp.intel.com>
References: <20110308164508.GA8729@darkside.kls.lan>
 <20110310165730.GC20504@alboin.amr.corp.intel.com>
 <20110310175411.GB25027@darkside.kls.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110310175411.GB25027@darkside.kls.lan>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 933
Lines: 23

> Would it be possible to make CPU-affinity configurable for *single*
> kcryptd instances? Either in the way to nail a specific kcryptd to a
> specific CPU or (what would be better for me, I guess) in the way to
> completely remove CPU-affinity from a specific kcryptd, like it was
> before?

I don't think that's a good idea. You probably need to find some way
to make pcrypt (parallel crypt layer) work for dmcrypt. That may
actually give you more speedup too than your old hack because
it can balance over more cores. 

Or get a system with AES-NI -- that usually solves it too.

Frankly I don't think it's a very interesting case, the majority
of workloads are not like that.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/