Re: Rep:Rep:Re: [f-cpu] little feed-back from the libre softawre meeting

[Michael Riepe <michael@stud.uni-hannover.de>]

On Mon, Jul 15, 2002 at 12:00:41PM +0000, Nicolas Boulay wrote:
> Et bien ! You're blown my mail box !

Oh, sorry ;)

> I) Page size
> 
> >From my last talk with Neal (the guy who port L4 to the Hurd and try to
> design a new VM for it), it appears that he's needs for page size are :
> - small for passing message, in that case increasing the page size
> doesn't decrease the number of the page because we allways have at least
> one page per message.
> - one medium for typical code and data.
> - one big for frame buffer and kernel page
> - one hudge for data base
> 
> small could be 4 Kb. 

That seems to be a reasonable lower limit.

> Neal propose at the beginning 64 kb for medium but if you do "top" on
> you're linux bow you will see very few program using 64 kb of memory (i
> beleive that one program have at least 3 pages). So maybe 16 kb or even
> 8 kb could be enought. Most of the time current OS use only a single
> size for paging system, so this size must be carefully choosen.
> If it's too big they will use the smallest size.
> 
> big are 4 Mo for like for intel big pages.
> 
> hudge could be 256 Mo, it's for data base system that used hudge amount
> of memory and use it's own memory allocator (so it will ask almost all
> the system's memory at start and then manage it). 

What about programs that have larger working sets? Especially on 64-bit
machines, you may have applications that use gigabytes of data and
have several megabytes of code space - and I want to be prepared for
such beasts. What is a 64-bit CPU good for, after all? Big stuff!

> Page size are important. Many object are page aligned. for example :
> library and files. If the page are too big, copy-on-write technique
> became less efficient.( on the average there is more data to copy than
> needed by smaller sized page).
> 
> The otherdraw back of many different size is that the OS must find "big
> and aligned hole" in memory to give such pages to a program and that
> could be hard !(having many sized from 4kb could help to reduice such
> problem)

A buddy system allocator with power-of-two page sizes should be ok.

> It could be very important to have 2 tlb (one for data and one for
> code), it's quite unusual to mix the 2 kind of pages. So you could save
> one port to the tlb or double the bandwith of the all system. (it could
> be very important if we keep the L1 cache in the physical address space
> and check at allmost every memory access the tlb)

There's no need to check the TLB on every instruction fetch. The
virtual->physical mapping remains valid until we leave the page or the
TLB entry is changed or invalidated - and that will be rather rare if
the compiler generates good code.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/