On Tue, Mar 30, 2010 at 11:35:01AM -0500, Christoph Lameter wrote:
> On Tue, 30 Mar 2010, Andrea Arcangeli wrote:
>
> > > Looks like SLUB also uses _mapcount for some fun purposes:
> > >
> > > struct page {
> > > unsigned long flags; /* Atomic flags, some possibly
> > > * updated asynchronously */
> > > atomic_t _count; /* Usage count, see below. */
> > > union {
> > > atomic_t _mapcount; /* Count of ptes mapped in mms,
> > > * to show when page is mapped
> > > * & limit reverse map searches.
> > > */
> > > struct { /* SLUB */
> > > u16 inuse;
> > > u16 objects;
> > > };
> > > };
> > >
> > > I guess those don't *really* become a problem in practice until we get a
> > > really large page size that can hold >=64k objects. But, at that point,
> > > we're overflowing the types anyway (or really close to it).
> >
> > Maybe we should add a BUG_ON in slub in case anybody runs this on
> > PAGE_SIZE == 2M (to avoid silent corruption).
>
> SLUB has been verified a long time ago to run fine with 2M pages.
>
> Just specify
>
> slub_min_order=9
>
> on the kernel command line to get a system booted up with 2M slab pages.
sure no doubt if order 9 == 2M it's no problem, what I meant is:
#define PAGE_SIZE (4096*512)
2M >>> 64k so with order 0 == 2m I thought it might overflow, dunno!
As far as PG_buddy removal is concerned, if I use -2 I don't think
there can be any problem as it'd be next to overflow anyway like Dave
said.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>