From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?B?SsO2cm4=?= Engel <joern@lazybastard.org>
Subject: Re: [Patch 14/18] fs/logfs/segment.c
Date: Mon, 4 Jun 2007 11:07:11 +0200
Message-ID: <20070604090711.GD14823@lazybastard.org>
References: <20070603183845.GA8952@lazybastard.org> <20070603184850.GO8952@lazybastard.org> <200706040021.43485.arnd@arndb.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org, akpm@osdl.org,
	Sam Ravnborg <sam@ravnborg.org>,
	John Stoffel <john@stoffel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Jamie Lokier <jamie@shareable.org>,
	Artem Bityutskiy <dedekind@infradead.org>,
	CaT <cat@zip.com.au>, Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	David Weinehall <tao@acc.umu.se>, Willy Tarreau <w@1wt.eu>,
	Kyle Moffett <mrmacman_g4@mac.com>,
	Dongjun Shin <djshin90@gmail.com>, Pavel Machek <pavel@ucw.cz>,
	Bill Davidsen <davidsen@tmr.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Albert Cahalan <acahalan@gmail.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Roland Dreier <rdreier@cisco.com>,
	Ondrej Zajicek <santiago@crfreenet.org>,
	Ulisses Furquim <ulissesf@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from lazybastard.de ([212.112.238.170]:54522 "EHLO
	longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751713AbXFDJLu (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 4 Jun 2007 05:11:50 -0400
Content-Disposition: inline
In-Reply-To: <200706040021.43485.arnd@arndb.de>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Mon, 4 June 2007 00:21:41 +0200, Arnd Bergmann wrote:
> On Sunday 03 June 2007, J=C3=B6rn Engel wrote:
> > +static DEFINE_MUTEX(compr_mutex);
> > +
>=20
> It seems you define a static compre_mutex in both segment.c and in co=
mpr.c,
> and always lock them both at the same time. Is that a correct observa=
tion?
> Is it intentional, or an oversight on your side?

Lame coding on my side.  Seems to have gone lost in my notes, but this
mutex should get removed and the protected memory made per-superblock.
Unlike the zlib workspace it does not consume 300k, so there is no
excuse for it here.

J=C3=B6rn

--=20
Joern's library part 9:
http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html