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 dHLYLzNMpY2W for ; Thu, 9 Feb 2012 11:19:33 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 9 Feb 2012 11:19:33 +0100 (CET) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19AJWgk022864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Feb 2012 05:19:32 -0500 Received: from [10.34.30.35] (tawny.brq.redhat.com [10.34.30.35]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q19AJU9U025939 for ; Thu, 9 Feb 2012 05:19:31 -0500 Message-ID: <4F339DB2.20603@redhat.com> Date: Thu, 09 Feb 2012 11:19:30 +0100 From: Milan Broz MIME-Version: 1.0 References: <1328567304.90926.YahooMailNeo@web29602.mail.ird.yahoo.com> <20120207081135.GC17107@tansi.org> <20120207083334.GA18260@tansi.org> <1328713497.10971.YahooMailNeo@web29605.mail.ird.yahoo.com> <20120208152645.GA17166@tansi.org> <1328723721.26190.YahooMailNeo@web29606.mail.ird.yahoo.com> <20120209073717.GA3176@tansi.org> In-Reply-To: <20120209073717.GA3176@tansi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Re : Re : Poor performances with nfs and Kernel 3.x List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 02/09/2012 08:37 AM, Arno Wagner wrote: > On Wed, Feb 08, 2012 at 05:55:21PM +0000, Mickael wrote: >> Here are more tests focusing the CPU load with htop snapshot: >> >> with Kernel 3.x, nfsd threads are using more CPU !? > > This is what I suspected. You setup is already slightly > CPU-limited when reading/writing encrypted partitions. > Any additional CPU needed by NFS is then directly deduced > from CPU available for encryption. Not sure if it help, but it would be interesting if you can try to use patch from this thread http://article.gmane.org/gmane.linux.kernel/1245748 (it can be completely unrelated though, I have no time to test it now myself) BTW I will add possibility to use null cipher to cryptsetup, just to test exactly these situations (null cipher eliminates all crypto operations), for now, you can try it with dmsetup and measure preformance (this should uncover if encryption is the problem or there is some timing problem): (Replace DEV with your disk, note key is "-" - means empty) dmsetup create x --table "0 $(blockdev --getsz DEV) crypt cipher_null-ecb-null - 0 DEV 0" Milan