Large framebuffers and HIGHMEM systems

Large framebuffers and HIGHMEM systems

[Jon Smirl]

Fbdev needs to come up with a general solution for mapping large framebuffers
on systems with over 1GB memory. For example my system does not have 64MB of
free address space below 1GB, this causes my framebuffer drivers to fail when
loading. With RAM prices at $200 for 1GB memory 1GB systems will be common
during the 2.6 timeframe.

There are many possible solutions...
1) add reserve=XXXX to the kernel at boot. Drawback to this is reserving
256-512MB takes this memory out of lowmem kernel use. This will push page
tables into highmem slowing the whole system down.
2) Only map a 2048x2048x32 piece of the framebuffer. This still uses 16MB of
address space which may not always be available. It could be possible to modify
the kernel to always reserve this much address space at boot.
3) Only map what is actually needed on each mode change. Mode change could fail
at run time if not enough free address space.
4) Map the buffer into the highmem address space using the highmem access
macros.
5) Map the fb in a user process and send it signals to draw.

I would also suggest modifying all current fb drivers to print a message about
adding reserve=xxxxx at boot if their ioremap() of the fb fails. This will at
least point people at an immediate work around.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[Geert Uytterhoeven]

On Tue, 9 Sep 2003, Jon Smirl wrote:
> Fbdev needs to come up with a general solution for mapping large framebuffers
> on systems with over 1GB memory. For example my system does not have 64MB of
> free address space below 1GB, this causes my framebuffer drivers to fail when
> loading. With RAM prices at $200 for 1GB memory 1GB systems will be common
> during the 2.6 timeframe.

> I would also suggest modifying all current fb drivers to print a message about
> adding reserve=xxxxx at boot if their ioremap() of the fb fails. This will at
> least point people at an immediate work around.

Or modify ioremap() to print the message? This problem is not only limited to
frame buffer devices, but to every driver that needs to ioremap() large
regions, right?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[Jon Smirl]

--- Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Or modify ioremap() to print the message? This problem is not only limited to
> frame buffer devices, but to every driver that needs to ioremap() large
> regions, right?
> 
ioremap() is supposed to map the region into the bottom 1GB or fail. After
ioremap() fails you need to use a different API to map to the highmem regions.
The way Linux is set up there is always about 20-30MB of free address space
below 1GB. All of the hardware I've seen can map into that space. The only
exception is the huge amount of address space needed for kernel mapped video
frame buffers.

Memory below 1GB is important to the kernel for keeping page tables. Page table
can be pushed above 1GB but you incur performance penalties. There is no
problem creating a 256MB hole with reserve=XXXX in the 1GB address space to
allow the latest ATI/NV cards to run with framebuffers; but doing this will
slow your system down. It is also a very non-obvious solution to why a
framebuffer fails to load.

I don't think we should be forcing non-performance sensitve framebuffer memory
into the bottom 1GB and pushing performance sensitive page tables into highmem.
Besides, we are going that have to do something, we are likely to have 1GB
video cards two years from now.


=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[Sven Luther]

On Wed, Sep 10, 2003 at 08:01:00AM -0700, Jon Smirl wrote:
> --- Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Or modify ioremap() to print the message? This problem is not only limited to
> > frame buffer devices, but to every driver that needs to ioremap() large
> > regions, right?
> > 
> ioremap() is supposed to map the region into the bottom 1GB or fail. After
> ioremap() fails you need to use a different API to map to the highmem regions.
> The way Linux is set up there is always about 20-30MB of free address space
> below 1GB. All of the hardware I've seen can map into that space. The only
> exception is the huge amount of address space needed for kernel mapped video
> frame buffers.
> 
> Memory below 1GB is important to the kernel for keeping page tables. Page table
> can be pushed above 1GB but you incur performance penalties. There is no
> problem creating a 256MB hole with reserve=XXXX in the 1GB address space to
> allow the latest ATI/NV cards to run with framebuffers; but doing this will
> slow your system down. It is also a very non-obvious solution to why a
> framebuffer fails to load.
> 
> I don't think we should be forcing non-performance sensitve framebuffer memory
> into the bottom 1GB and pushing performance sensitive page tables into highmem.
> Besides, we are going that have to do something, we are likely to have 1GB
> video cards two years from now.

We already have 512MB ones, i guess you will not have to wait for as
long as two years for 1GB video cards.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[Geert Uytterhoeven]

On Wed, 10 Sep 2003, Sven Luther wrote:
> On Wed, Sep 10, 2003 at 08:01:00AM -0700, Jon Smirl wrote:
> > Besides, we are going that have to do something, we are likely to have 1GB
> > video cards two years from now.
> 
> We already have 512MB ones, i guess you will not have to wait for as
> long as two years for 1GB video cards.

Great!

So I can speed up my poor 128 MB PPC machine by buying such a card and swapping
to the unused portion of the video RAM, instead of trying to find real 2-bank
SDRAM DIMMs :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[Sven Luther]

On Wed, Sep 10, 2003 at 06:21:45PM +0200, Geert Uytterhoeven wrote:
> On Wed, 10 Sep 2003, Sven Luther wrote:
> > On Wed, Sep 10, 2003 at 08:01:00AM -0700, Jon Smirl wrote:
> > > Besides, we are going that have to do something, we are likely to have 1GB
> > > video cards two years from now.
> > 
> > We already have 512MB ones, i guess you will not have to wait for as
> > long as two years for 1GB video cards.
> 
> Great!
> 
> So I can speed up my poor 128 MB PPC machine by buying such a card and swapping
> to the unused portion of the video RAM, instead of trying to find real 2-bank
> SDRAM DIMMs :-)

They don't come as PCI versions yet though.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[James Simmons]

> Fbdev needs to come up with a general solution for mapping large framebuffers
> on systems with over 1GB memory. For example my system does not have 64MB of
> free address space below 1GB, this causes my framebuffer drivers to fail when
> loading. With RAM prices at $200 for 1GB memory 1GB systems will be common
> during the 2.6 timeframe.
> 
> There are many possible solutions...
> 1) add reserve=XXXX to the kernel at boot. Drawback to this is reserving
> 256-512MB takes this memory out of lowmem kernel use. This will push page
> tables into highmem slowing the whole system down.

NOPE!!!!

> 2) Only map a 2048x2048x32 piece of the framebuffer. This still uses 16MB of
> address space which may not always be available. It could be possible to modify
> the kernel to always reserve this much address space at boot.

I was thinking about a solution like this. We have to consider that alot 
of drivers use the extra memory space to do hardware panning to create a
scrolling effect. We could set a limit to the amount of memory mapped for 
this effect. 

> 3) Only map what is actually needed on each mode change. Mode change could fail
> at run time if not enough free address space.

That is acceptable. I doubt it would fail all the time. We lose th 
eperformance boost for scrolling tho :-(

> 4) Map the buffer into the highmem address space using the highmem access
> macros.

We could do a partial mapping into highmem space. Lomem memory what we are 
using now. High memory for what we need less often.

> 5) Map the fb in a user process and send it signals to draw.

Yuck!!

The good news is fully accelerated drivers don't need to ioremap the 
entire range in memory at one time. screen_base is not much use to them. 
The only place this is not true is fb_read and fb_write. We could setup a 
blitting engine use tho :-) Then of course mmap a huge framebuffer to 
memory would fail then with 1 GB memory systems. 

P.S
    How bad is the cost to access high memory?




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Large framebuffers and HIGHMEM systems

[Jon Smirl]

--- James Simmons <jsimmons@infradead.org> wrote:
> > Fbdev needs to come up with a general solution for mapping large
> framebuffers
> > on systems with over 1GB memory. For example my system does not have 64MB
> of
> > free address space below 1GB, this causes my framebuffer drivers to fail
> when
> > loading. With RAM prices at $200 for 1GB memory 1GB systems will be common
> > during the 2.6 timeframe.
> > 
> > There are many possible solutions...
> > 1) add reserve=XXXX to the kernel at boot. Drawback to this is reserving
> > 256-512MB takes this memory out of lowmem kernel use. This will push page
> > tables into highmem slowing the whole system down.
> 
> NOPE!!!!

This is what I have to do right now with 1GB of memory and a 64MB Radeon on
2.6. We need to fix this. We should also add an error message right now to
framebuffer ioremap()'s telling users that this what they need to do to get
around the failure.

> 
> > 2) Only map a 2048x2048x32 piece of the framebuffer. This still uses 16MB
> of
> > address space which may not always be available. It could be possible to
> modify
> > the kernel to always reserve this much address space at boot.
> 
> I was thinking about a solution like this. We have to consider that alot 
> of drivers use the extra memory space to do hardware panning to create a
> scrolling effect. We could set a limit to the amount of memory mapped for 
> this effect. 
> 
> > 3) Only map what is actually needed on each mode change. Mode change could
> fail
> > at run time if not enough free address space.
> 
> That is acceptable. I doubt it would fail all the time. We lose th 
> eperformance boost for scrolling tho :-(

If you boot in a low res mode, mode changing to a higher res may fail because
there is not enough address space. Trying to fit into the small amount of
remaining VM space may  fragment it preventing you from getting 64MB of
contiguous address space.

> 
> > 4) Map the buffer into the highmem address space using the highmem access
> > macros.
> 
> We could do a partial mapping into highmem space. Lomem memory what we are 
> using now. High memory for what we need less often.
> 
> > 5) Map the fb in a user process and send it signals to draw.
> 
> Yuck!!

I'd like to hear a good explanation of why we need to draw to framebuffers in
the kernel. I'm starting to think that we should draw on whatever the BIOS sets
up untill user space is active. Then point the kernel to a user space process
that draws the console for specific hardware. Kernel VESA fb would always be
loaded as back up in case these processes die. User space proccesses don't have
the same problem with virtual memory address space shortages.

> The good news is fully accelerated drivers don't need to ioremap the 
> entire range in memory at one time. screen_base is not much use to them. 
> The only place this is not true is fb_read and fb_write. We could setup a 
> blitting engine use tho :-) Then of course mmap a huge framebuffer to 
> memory would fail then with 1 GB memory systems. 
> 
> P.S
>     How bad is the cost to access high memory?
> 
High mem might be the best solution. Make a rule that kernel framebuffers are
always mapped to high memory. I'd make it a rule so that this code will get
tested on all systems not just a few with 1GB today. Either your page tables
are going into high memory or your framebuffer is, if you ask me there is no
choice about this and the framebuffer is going high.

I have never used highmem before but I think it works something like this.
First we need some way to ioremap() to a highmem address.  Then before each
access to a high mem address there is a macro for converting the high mem
address to a low mem one, and then another macro for freeing it. These marcos
mess with a page table entry for a low mem page and make it point to the high
mem one. There are a limited number for page table entries reserved for this
process so you need to keep mapping and unmapping.

This is slow to a CPU but not to a human,  we're doing an APG or PCI memory
cycle which takes forever anyway. And it sure is easier than explaining why a
system won't boot because it is out of kernel virtual memory space.

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf