From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p6zgF6Gxhwr for ; Sun, 16 Dec 2012 22:44:07 +0100 (CET) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 16 Dec 2012 22:44:07 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TkM0P-00046N-Hw for dm-crypt@saout.de; Sun, 16 Dec 2012 22:44:17 +0100 Received: from d67-193-232-12.home3.cgocable.net ([67.193.232.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Dec 2012 22:44:17 +0100 Received: from brian by d67-193-232-12.home3.cgocable.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Dec 2012 22:44:17 +0100 From: "Brian J. Murrell" Date: Sun, 16 Dec 2012 16:43:50 -0500 Message-ID: <50CE4096.5030508@interlinx.bc.ca> References: <5022883B.8070909@gmail.com> <50CDBA37.1050308@interlinx.bc.ca> <50CE0FAE.6030707@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3916436F9428CA5AE532D201" In-Reply-To: <50CE0FAE.6030707@gmail.com> Subject: Re: [dm-crypt] dm-crypt multithreaded yet? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3916436F9428CA5AE532D201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12-12-16 01:15 PM, Milan Broz wrote: >=20 > No idea why it turned world non-readable, fixed. Thanks. > But I am afraid I did not find any real situation where these patches > really helps If successive block I/Os from a sequential I/O can all get queued up by different CPU (cores) I can't imagine why that wouldn't help. > See also discussion on dm-devel list, I still think generic > kernel workqueues should be used to provide such parallelization and > we should not duplicate code in dm-crypt... Well, definitely, if the parallelization work is duplicating existing kernel functionality, that needs to be factored out. But regardless... > My suggestion is that using AES-NI extension helps much more with > the current upstream code than anything else (for AES, obviously). But of course. I am sure anyone that has a CPU with AES-NI instructions wouldn't care so much (at all even) about multi-core dm-crypt. But unfortunately not everyone has AES-NI capable processors, yet they might have 4 cores (8 if HT enabled) available, with 3 (7, again if HT is enabled) all sitting around doing nothing while one is grunting away with all of the workload. I wish I could just trade in my laptop for one with AES-NI, but other than the lack of AES-NI it's far better than what I would get in return for trading it in. Kind of like trading in one's Ferrari just because it doesn't have a leather steering-wheel for a Fiat that does have a leather steering wheel. :-/ Cheers, b. --------------enig3916436F9428CA5AE532D201 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDOQJYACgkQl3EQlGLyuXDlvQCfUgNNX0wbxYrtns5jIrgGUXDj TxAAnjid8aE8UdkK3YXEDSVx0mHxOVyf =IeOQ -----END PGP SIGNATURE----- --------------enig3916436F9428CA5AE532D201--