From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757055AbcFADRl (ORCPT ); Tue, 31 May 2016 23:17:41 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:33951 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752788AbcFADRj (ORCPT ); Tue, 31 May 2016 23:17:39 -0400 Date: Wed, 1 Jun 2016 12:17:35 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Joonsoo Kim , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 4/8] zram: use crypto api to check alg availability Message-ID: <20160601025236.GG461@swordfish> References: <20160531122017.2878-1-sergey.senozhatsky@gmail.com> <20160531122017.2878-5-sergey.senozhatsky@gmail.com> <20160601000304.GF19976@bbox> <20160601010707.GB461@swordfish> <20160601022708.GL19976@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160601022708.GL19976@bbox> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (06/01/16 11:27), Minchan Kim wrote: [..] > > > So, if we do 'cat /sys/block/zram0/comp_algorithm", every crypto modules > > > in the backend array are loaded in memory and not unloaded until admin > > > executes rmmod? Right? > > > > yes, I think so. > > It scares me. Common case, except one we choosed, every loaded modules > will be not used. I think it's really not good. Although the wastage > might be not big now, it will be heavy as crypto comp modules are > increased. well... if you have those modules enabled then you somehow expect them to be loaded at some point, if not by zram, then by something else (networking, etc.). /* not speaking of the systems that have those modules built-in */ I'm not saying that what we have is optimal, of course, but it's not so senseless at the same time. > What do you think about it? I can do something like this: diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c index 1a4bd20..9b704cc 100644 --- a/drivers/block/zram/zcomp.c +++ b/drivers/block/zram/zcomp.c @@ -20,10 +20,18 @@ static const char * const backends[] = { "lzo", +#if IS_ENABLED(CONFIG_CRYPTO_LZ4) "lz4", +#endif +#if IS_ENABLED(CONFIG_CRYPTO_DEFLATE) "deflate", +#endif +#if IS_ENABLED(CONFIG_CRYPTO_LZ4HC) "lz4hc", +#endif +#if IS_ENABLED(CONFIG_CRYPTO_842) "842", +#endif NULL }; so both BUILTIN and BUILT-AS-A-MODULE cases are handled at compile time now and we can avoid crypto_has_comp() checks for most of the comp_algorithm calls, except for the case when someone requests an out-of-tree module. -ss