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

[Cedric BAIL <cedric.bail@free.fr>]

> >>From Cedric thinks :
> >     we need 3 sr : to set or unset the tbl 
> i presume that we will need much more, as the interface
> must remain clean and orthogonal throughout different
> core types... let's make something simple, logical
> and easy to understand from the beginning, even though if we
> don't use all the features now...
 
> >      something to change the ring
> >      for vm writter we must enable or not the read
> >       access to sr(trap on read AND write)

Ok, it's what not clear, I was only speaking about an activate/unactivate
TLB SR, that's only for protection mecanism. I didn't speak about the
way to put data in the TLB, it's still an open question. If someone have
an idea ;-)

> SRs will contain a place which says what the current user
> can read and/or write => not a problem (it's slow anyway, so...)
> it's not yet defined in the VHDL sources but will become
> a reality whenever the corresponding piece of code is written.
The problem I currently see is that you are not clear about this protection
mecanism. I mean I don't understand if you do a per range protection mecanism,
or a per SR protection or like the one I explain in a precedent mail.

I think that a per range or a per SR protection mecanism can become in the
futur a nightmare. And we must have some good performance when we only read
the SR. When you set SR, you must quickly know if you have the right or not,
typically a good OS will block the write on any SR, so only virtual OS need
to access them...

> >     16 kb for a page is a little bit to much
> why ? if you have huge datasets (megabytes, gigabytes...)
run top on your computer and see how many task need more than 8k ;-)

on my laptop, only 20%.

> you will spend your time in the trap handler...
Yes, it's why an "unified" TLB will be preferable to a lot of different one
because we can adjust dynamically the number of TLB entry per size page. I know
it perhaps a nightmare in hardware, but if somebody see a solution ;-)

And at least a guy who program a TLB miss handler say to me what is for him
the best solution from a software point of view (and I think that in hardware
it's a nightmare ;-). What you need to know when a TLB miss append, is to know
which line you can replace. So the best solution is to remove the one that's are
the less used. A system that "swap" TLB line and always say which line
is the less used really ease the TLB miss handler...

I currently didn't find a way to implement this in hardware, and I think
that a solution with a counter that are in read/write access is the best
solution for hardware and software.

> i count on the OS to "gather" contiguous small pages into
> larger ones, possibly based on usage statistics (that the
> CPU could gather).
The problem is with small task, and you have really a big number of small task.

> >     8 kb could be enough
> >     all new processor have between 5 to 11 page size !
> cool.
> however too many sizes might make the LSU more complex :-(
> i guess that 4 is the best tradeoff.
You know it's totally arbitrary, we currently can't know the impact of the
number of different page size, the number of line into the TLB and of course
the size of each page size.

I think that it depend on the use of the core, so what did you think to add
some read only SR that will say to the kernel all this information so that
we didn't need to re-"port" OS when we change the usage of the core (or in the
future when we need more bigger page size) ?

> ****************************
>   Don't let children look
> ****************************
Can I read this yann ? ;-)
 
> i just found a REALLY naughty  (cough)#hack# ....
 
> it doesn't soleve the page size problems
> but removes some "kernel addressing " problems,
> which make the LSU a bit more complex...
Can you explain it to us ?

> >     we should try to implement L4 (hurd main kernel) to verify the
> >       process management of the f-cpu
> whatever you want as long you #do# it ...
> you know the song....
But before we need an virtual machine and an assembler ;-)

> >     Looking for technics to handle different page size on the same
> >       memory for (tlb) to avoid the use of many independant memories
 
> my current method is to have N parallel TLBs with 
> one size each. Say, 8 entries for 4KB, 8 entries for 32KB,
> 8 entries for 256 etc...
I think that 4KB is really to small (did you see any process that can be
put into a so small page, and don't forget that we are 64bits CPU not a 32bits
so we need more place).

After discussing with Neal, 8KB and 8MB will be necessary, for other size it's
really a random decision ;-)

At least, only 8 entries per TLB is really small, you can put a lot of task
running at the same time (I think that ľKernel will dislike this and all the
server that handle many connection at the same time). 

Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/