Re: UVM aobj: Large VM objects.

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Mon, 06 Mar 2006 18:11:04 +0900
YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> wrote:

> > On Mon, Mar 06, 2006 at 05:56:22PM +0900, YAMAMOTO Takashi wrote:
> > > > On Mon, Mar 06, 2006 at 05:32:48PM +0900, YAMAMOTO Takashi wrote:
> > > > > (although i doubt kernel_object really need to cover the entire 
> > > > > region,)
> > > > > making aobj 64-bit offset clean is a good idea.
> > > > > 
> > > > > however, i don't think long is appropriate here.
> > > > > please introduce a 64-bit "page offset" type.
> > > > > "typedef voff_t pgoff_t" should be fine.
> > > > 
> > > > Won't this make 32-bit ports slower?
> > > 
> > > which part of code are you talking about?
> > 
> > The original proposal was to make the u_pages member long. Are you
> > proposing to make it a 64-bit type, or did I misunderstand something? And
> > aren't 64-bit operations on 32-bit cpus slow?
> 
> given that fast path uses 64-bit types already, i don't think it will
> have serious impacts.  i asked because i thought you knew the particular
> piece of code which can be affected seriously.
> 
Make it a typedef and try it; if it's too slow, we only have to change
it in one spot.