From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [patch 1/3] add the fsblock layer Date: Mon, 25 Jun 2007 10:58:26 +0200 Message-ID: <20070625085826.GA19928@one.firstfloor.org> References: <20070624014528.GA17609@wotan.suse.de> <20070624014613.GB17609@wotan.suse.de> <1182716322.6819.3.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andi Kleen , Nick Piggin , Linux Kernel Mailing List , Linux Memory Management List , linux-fsdevel@vger.kernel.org To: Arjan van de Ven Return-path: Received: from one.firstfloor.org ([213.235.205.2]:34022 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751122AbXFYI63 (ORCPT ); Mon, 25 Jun 2007 04:58:29 -0400 Content-Disposition: inline In-Reply-To: <1182716322.6819.3.camel@laptopd505.fenrus.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, Jun 24, 2007 at 01:18:42PM -0700, Arjan van de Ven wrote: > > > Hmm, could define a macro DECLARE_ATOMIC_BITMAP(maxbit) that expands to the smallest > > possible type for each architecture. And a couple of ugly casts for set_bit et.al. > > but those could be also hidden in macros. Should be relatively easy to do. > > or make a "smallbit" type that is small/supported, so 64 bit if 32 bit > isn't supported, otherwise 32 That wouldn't handle the case where you only need e.g. 8 bits That's fine for x86 too. It only hates atomic accesses crossing cache line boundaries (but handles them too, just slow) -Andi