Re: Reduce struct page by 8 bytes on 64bit

Andrew Morton
2003-04-16T21:32:24Z

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.