2002-03-17 02:50:48

by Chris Wedgwood

[permalink] [raw]
Subject: Re: [Lse-tech] Re: 10.31 second kernel compile

On Sat, Mar 16, 2002 at 09:05:04PM +0100, Andi Kleen wrote:

On Sat, Mar 16, 2002 at 12:57:11PM -0700, [email protected]
wrote:

>
> What about 2M pages?

They are not supported for user space, but used in private
mappings for kernel text and direct memory mappings. Generic code
never sees them.

Is there any reason we couldn't use them for mapping large
frame-buffers and similar?



--cw


2002-03-17 03:29:30

by Alan

[permalink] [raw]
Subject: Re: [Lse-tech] Re: 10.31 second kernel compile

> They are not supported for user space, but used in private
> mappings for kernel text and direct memory mappings. Generic code
> never sees them.
>
> Is there any reason we couldn't use them for mapping large
> frame-buffers and similar?

You are labouring under the belief that processors touch the frame buffer
nowdays. For a current accelerated frame buffer that isnt very true.

2002-03-17 04:13:04

by Chris Wedgwood

[permalink] [raw]
Subject: Re: [Lse-tech] Re: 10.31 second kernel compile

On Sun, Mar 17, 2002 at 03:43:29AM +0000, Alan Cox wrote:

You are labouring under the belief that processors touch the frame
buffer nowdays. For a current accelerated frame buffer that isnt
very true.

/s/frame-buffer/hunk-of-memory/

Either way, we have tens of MB of ram where we either put textures,
options or whatever --- the CPU has to meddle with it one way or
another.



--cw

2002-03-17 04:17:24

by Alan

[permalink] [raw]
Subject: Re: [Lse-tech] Re: 10.31 second kernel compile

> Either way, we have tens of MB of ram where we either put textures,
> options or whatever --- the CPU has to meddle with it one way or
> another.

The disk DMA's it to RAM, the graphics card fetches it via the GART
mappings. We shouldn't be touching a lot of it.