linux-kernel - Re: [PATCH] zram percpu implementation

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>] [day] [month] [year] [list]

Date:	Tue, 16 Jul 2013 15:37:07 -0400
From:	Valdis.Kletnieks@...edu
To:	mani <manishrma@...il.com>
Cc:	nitingupta910@...il.com, gregkh@...uxfoundation.org,
	devel@...verdev.osuosl.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernelnewbies@...nelnewbies.org
Subject: Re: [PATCH] zram percpu implementation

On Wed, 17 Jul 2013 00:27:34 +0530, mani said:

> This patch will create a percpu structures compression algo.
> 1. Takes extra memory for workspace buffers.
> I haven't seen any performance gain with this need to find the
> root cause.

My first guess is that the higher-level zram stuff is submitting
its requests sequentially, so there's very few occasions where more
than one page is waiting for (de)compression handling at the same time.

You change the logic of zram_bvec_(read/write) - but what you'd need to
change is the code that *calls* it so that there's multiple bvec_* calls
in flight at the same time.

+    for_each_possible_cpu(cpu) {
+        printk(KERN_EMERG"[%s] Initializing for each core %d\n", cpu);

KERN_EMERG?  No.  Absolutely not.

Content of type "application/pgp-signature" skipped