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

Jörn Engel (joern@wohnheim.fh-wedel.de)
Mon, 2 Jun 2003 17:36:56 +0200


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
think?

Jörn

-- 
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/