Re: Reduce struct page by 8 bytes on 64bit

[Andrew Morton <akpm@digeo.com>]

Matthew Wilcox <willy@debian.org> wrote:
>
> On Wed, Apr 16, 2003 at 01:35:39PM -0700, Andrew Morton wrote:
> > Matthew Wilcox <willy@debian.org> wrote:
> > >
> > > Jacob's would break if we hashed to different spinlocks.  But we don't, we
> > > shift right by 8, so we get the same spinlock for atomic things that are on
> > > the same "cacheline" (i think PA cachelines are actually 64 or 128 bytes,
> > > depending on model).
> > > 
> > 
> > Are you prepared to cast this in stone?
> 
> I think so.  It makes sense to me that we lock an entire cacheline for
> this kind of thing.  Indeed, locking a smaller amount would probably break
> other stuff.  Remember set_bit() et al take a pointer to an unsigned long...
> but can take a bit number > number of bits in an unsigned long.  If anything,
> we should maybe expand the range covered by a single lock to a larger amount
> than 256 bytes.

Well are we sure that the `flags' and `count' fields will always fall into
the same 256-byte range?  Wouldn't it subtly break if sizeof(struct page)
became not a multiple of eight?  Will the compiler pad it out anyway?

> How big are ext2 bitmaps, for example?

They can be 8k, rarely.  Usually 4k.  But ext2_set_bit() and friends are
nonatomic - the filesystem does the locking.

We just added the new ext2_set/clear_bit_atomic() functions which _are_
supposed to be atomic.  The architecture is passed a spinlock which it can
use for that, but only big-endian architectures are likely to need it.