In any case I wish all accesses to struct vm_page are wrapped by
macros/functions. Hopefully FS modules always use functions so
that the structure can be opaque.
On Mon, Apr 04, 2011 at 02:17:44PM +0000, Andrew Doran wrote:
> 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.
Sounds reasonable to me.
>
> 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.
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
