On Mon, Apr 04, 2011 at 09:08:51AM +1000, matthew green wrote:
>
> > On Sun, Apr 03, 2011 at 07:35:04PM +1000, matthew green wrote:
> > >
> > > > Ignoring the free page allocator which abuses pg->offset, is there any
> > > > reason we cannot fold pg->flags into pg->offset? The lower PAGE_SHIFT
> > > > bits
> > > > of pg->offset are not used.
> > >
> > > is this about making vm_page smaller? if so, and it works, i guess that
> > > seems fine, but how many bits do you want to use? ie, what is the
> > > smallest PAGE_SIZE we will support?
> > >
> > > if not that, why?
> >
> > And is the memory saved enough to be significant compared to the
> > number of masking operations needed to get pg->offset.
>
> actually, it won't really help unless we rearrange a lot more in
> vm_page{}. right now the flags member is 1 uint16_t in a series
> of 4 in a row, so removing one is unlikely to help, as it will
> just introduce padding on most platforms.
I'm considering the mechanics of introducing an additional field to give CPU
affinity to pages. This would be used to hash out uvm_pageqlock and the
inactive/active lists by CPU. Very much like we do for callouts, they have
weak CPU affinity and so there's almost no lock/cache contention on the
callout state.
Since we have a bunch of sub-word sized fields in vm_page the placement of
new fields is tricky, as they need to be locked the same as adjacent fields
in the same 32-bit cell. Merging pg->flags into pg->offset is attractive
because the same cell locking where pg->flags is would work for the purpose
I'm thinking of, and it would use no more space in vm_page.
