linux-kernel - Re: dm-crypt: Performance Regression 2.6.37 -> 2.6.38-rc8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110311011842.GA5698@alboin.amr.corp.intel.com>
Date:	Thu, 10 Mar 2011 17:18:42 -0800
From:	Andi Kleen <ak@...ux.intel.com>
To:	Mario 'BitKoenig' Holbe <Mario.Holbe@...Ilmenau.DE>,
	dm-crypt@...ut.de, linux-kernel@...r.kernel.org,
	Milan Broz <mbroz@...hat.com>,
	Alasdair G Kergon <agk@...hat.com>
Subject: Re: dm-crypt: Performance Regression 2.6.37 -> 2.6.38-rc8

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/