tech-kern archive

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

Re: pg->offset and pg->flags

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.

Home | Main Index | Thread Index | Old Index