[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ?



hello,

i have just woken up and saw this thread degenerate without
bringing a single solution. i don't want to walk in this,
though i seem to agree with Christophe, but i just wanted to
point a few details that were apparently misinterpreted.

Marco Al wrote:
> From: "Christophe" <christophe.avoinne@laposte.net>
> 
> > Ok, lookup at this case (something like a memory pipe) in the same address
> > space :
> >
> > - a thread wants to share a memory space where it could only read.
> > - another thread wants to share the same memory space where it could only
> > write.
> >
> > The only solution is having two different virtual addresses with different
> > access rights pointing upon the same physical addresses.
> >
> > With virtual-addressed cache and virtual tags, the thread wouldn't read
> > the right value after the other
> > thread write because they use different entries in the cache.
> >
> > So even with your lazy solution, it is still impossible to do so.
> 
> Threads are scheduled by the OS, if you really wanted to the OS could just
> change the protection when it switches between threads (with the method
> described in the section in the paper I pointed out before). As I conceded
> before you need individual protection spaces, but that does not equal
> individual memory spaces.

changing the protection when switching the processes/tasks/threads
looks ugly for me.

> Alternatively/additionally you could use a segment based approach with per
> segment protection flags and just change the segment registers when
> switching threads ... with variable sized segments that would work out
> pretty well IMO, an important aspect is that it can work with SMT.

i think that F-CPU is already complex enough with only paged/virtual memory,
adding segments woud be a mess. Unless you mean a "fence" mechanism,
but then only a fence or a few shoud be active at a time.

> > An extended case : 1 provider, n consumers
> >
> > - a thread wants to share a memory space where it could read and write.
> > - n threads wants to share the same memory space where it could only read.
> 
> The same solution as above applies.
> 
> What I dont understand is why you would want to use memory mapped to two
> seperate memory ranges within the same process, because the memory isnt
> really protected ...

it's only a problem of terminology, i think. What if your threads belong
to different tasks or processes or whatever ? in short : Virtual Memory IDs...

> > My opinion is that we should never try to put anything in the sofware
> > corner. The end user is not an
> > hardware person but a software person who would like to have choice to use
> > a unique address space or seperate address spaces for his/her processes.
> 
> The set of users who could not get over it probably share a good number of
> people with the set of users who want machine's with lots of speculation,
> instruction reordering, huge caches and automatic prefetch mechanisms ...
> all there to mitigate the performance hit poorly targeted and implemented
> software gets. FCPU is not the processor for that second set of people, and
> I doubt very many of the first group remain afterwards.

it took a lot of time before i was able to use the 386 protected mode,
and i did not even use the virtual memory. I don't know what part i belong to.

If i was alone with F-CPU, there would be no paging, just a few sets of fences.
there would have been no debate, porting any OS (except UNICOS) would be a mess
but F-CPU would probably work.

Don't you think that a CPU with a decent number of TLB entries and a physical
tagged cache is enough to make an OS that is not too hairy ?

> You would hope that the average user which is already ready to accept the
> FCPU would also recognise it when this mechanism would provide him with
> everything he needed, which is still open for debate, even if it means doing
> some things differently ... and is more appreciative what allowing
> simplification of the hardware and removal of the TLB bottleneck gives him
> in performance and cost terms.

Considering that all the sources are copylefted, anybody is free to make his
own version in case one doesn't like it. However, for this to ever happen,
we have to write these sources...


Good night everybody,

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