tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pg->offset and pg->flags



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


Home | Main Index | Thread Index | Old Index