Subject: Re: UVM aobj: Large VM objects.
To: YAMAMOTO Takashi <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 03/06/2006 09:23:19
On Mon, 06 Mar 2006 18:11:04 +0900
YAMAMOTO Takashi <email@example.com> 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.