lkml.org 
[lkml]   [2003]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Reduce struct page by 8 bytes on 64bit
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.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.062 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site