Kernel configuration options

[John Richard Moser]

Jordan Crouse wrote:
> On 02/01/08 08:18 -0500, Bernardo Innocenti wrote:
>> Tom Sylla wrote:
>>
>>> http://openbios.org/viewvc/cpu/x86/pc/olpc/lxmsrs.fth?view=markup&revision=739&root=OpenFirmware
>>> has:
>>>   msr: 0000.1810 fdfff000.fd000111.  \ Video (write through), fbsize
>>>
>>> which is setting the framebuffer as write-combining. (the "write
>>> through" comment is incorrect)
>> This takes care of the physical mapping, but how would userspace
>> be able to mmap the framebuffer into virtual memory without
>> additional MMU programming?
>>
>> I was under the impression that we also need to cover the whole
>> region with small 4KB MMU pages.  This degrades performance
>> somewhat due to TLB misses when the CPU accesses the framebuffer.
> 
> Well, in an ideal world, we wouldn't need to read framebuffer so much
> that any performance hit would be small, especially with as big a 
> offscreen buffer as we have.
> 
> I know that this is not an ideal world, and there is some X breakage
> that reads and writes a lot from the framebuffer, but quite frankly,
> thats the least of our speed worries right now.
> 
> But out of curiosity, what you would you have us do differently?  Are you
> advocating that we move to 4Mb pages?
> 

YES.  You can mix and match your page sizes, have some pages 4MiB and 
some 4KiB.  If a block of i.e. the heap is 4MiB long, the kernel can 
technically relocate all 1024 involved pages so they're physically 
contiguous and aligned to a 4MiB boundary, and then remap them as one 
huge page.  It would have to handle an munmap() or brk() (shrinking) 
call by breaking it back up; but it could be done.

There's no reason with video memory sizes like 4M, 8M, 16M, 32M, 64M, 
256M, and these days even 512M that these kinds of mappings should use 
4KiB pages anymore.  Unlike the heap or anonymous mmap() segments, video 
memory doesn't change size and doesn't eat physical memory (*cough*); 
and unlike file-backed shared mmap() segments, you can't free up space 
by evicting the contents from memory if nobody's using it.


> Jordan
> 

-- 
Bring back the Firefox plushy!
http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good
https://bugzilla.mozilla.org/show_bug.cgi?id=322367