Re: [PATCH RFC] 1/2 central workspace for zlib

From: Jörn Engel (
Date: Mon Jun 02 2003 - 10:36:56 EST

On Tue, 3 June 2003 00:15:56 +0900, matsunaga wrote:
> But I still would like to stick to performance.
> (Though I haven't evaluated the performance yet...)
> So far I think MTD is used mostly on Embedded device,
> in which single CPU which is not so powerful is used.
> How is the following code (it is ugly though)?
> static void default_workspace[WSIZE];
> <snip>
> size = MAX(sizeof(struct inflate_workspace),
> sizeof(struct deflate_workspace));
> if(WSIZE < size)
> BUG();
> zlib_workspace[0] = default_workspace;
> for (i=1; i<smp_num_cpus; i++) {
> zlib_workspace[i] = vmalloc(size);
> if (!zlib_workspace[i]) {
> zlib_exit();
> return -ENOMEM;
> }
> }

Not bad. We can even do a little better. Since only one workspace is
really absolutely necessary (ignoring the siftirq case), there is no
need to fail anymore. If we don't get enough memory for all
workspaces, initialize the semaphore to be a little lower and live
with fewer workspaces.

I like your ideas, really! :)

> There is another vmalloc in mtdblock_open()...;-)

...that is not trivial to get rid of. Image the case where two
processes are writing to two devices. With two buffers, we do rmew
whenever switching blocks for one device. With one buffer, we have to
do it for every context switch between those two processes, which will
wear down the flash a lot faster.

Considering that mtdblock should not be performance critical in
production use anyway, this is a very hard problem. What do you


The only real mistake is the one from which we learn nothing.
-- John Powell
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Jun 07 2003 - 22:00:17 EST