Re: Rep:[f-cpu] Hot issue : external LSU ?

[nico <nicolas.boulay@ifrance.com>]

Christophe Avoinne a écrit :
> 
> ----- Original Message -----
> From: "nico" <nicolas.boulay@ifrance.com>
> To: <f-cpu@seul.org>
> Sent: Saturday, August 31, 2002 10:18 PM
> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ?
> 
> > Does it have one single lock bit for the whole system or a lock bit per
> > adress line ?
> 
> Well, maybe the name of lock bit is not appropriate since we don't lock but
> something like a no-dirty bit in fact . This bit is per address line since
> it is located in a LSU entry. Normally, a 'll' sets a LSU entry - like a
> normal load as well, and 'sc' should be executed as soon as possible (should
> be just a matter of few cycles), so we can expect the lsu entry would most
> time (a really good percentage) still be valid. Situations where a rollback
> must be done are rarer than you think.
> 
> > If there is only one, in large scale system, there will have a problem.
> 
> Forget it, I never think about a global lock anyway.
> 

Ok !

> > If there is one by address line, can't have a flag for each line so the
> > memory will act as a caches. So you could "loose" some lock bit, because
> > there isn't enough room.
> 
> The problem is same as for normal load/store : data must be in LSU. As I
> said above, 'll' then 'sc' must be executed in a very few laptime so
> "loosing" a no-dirty bit shouldn't be so critical as you seem to think.
> 
> > If you have a lot of process or a lot of
> > memory, soonre or later you will have a big problem.
> 
> ??? nope because the time between a 'll' and 'sc' is very short and can be
> spoken in cycles. Processes should not abuse the 'll/sc' the same way with
> normal load/store.
> 

Imagine 32 node with Apache process&thread. In the worst case, you could
go in infinite loop, no ?

> > For CAS, it's a little easier. The io bus (opppose to the memory bus)
> > should have read-modify-write cycle.
> > This kind of cycle will "lock" for a little moment all the system from the
> cpu
> > to the memory what ever way it cross. That's possible.
> 
> No doubt it is possible but you really lock the memory bus for all cpus
> indeed.
>

It's depend on topology of the network. But network is much slower than
cpu so if we care about that very few cycle will be lost.
 
> If a cpu want to read normally (with a normal load), it would be blocked too
> without reason.
> 

If the bus is locked, yes. Maybe with split CAS cycle ? The destination
of the load is locked during few cycle waiting for the conditionnal
store. Or you define not a read-modify-write cycle but a true CAS cycle.
The comparaison is maid by the controler (adresse of the load, data to
be compare and the write). The return is just an ack.

> If you want only intra-cpu locking, you are still preventing the other cpu
> from normal load/store operation.
> 

I don't like to differ inter and intra cpu process operation. Otherwise,
2 thread running on the same cpu will not have the same code as 2 thread
running on 2 cpu. And that's baaaaaad !

> > The performance is very poor but is much
> > quicker than a mutex.
> 
> Maybe you shouldn't think always the worse case as if it is 100%.
> 
> Just imagine that 'll/sc' is twice as fast as a 'CAS' and has 95% of success
> (no rollback). Overall performance is in fact better for 'll/sc'.
> 

The external LSU means a set/unset for each access and that is a cost
for each memory access.

> > If we add CAS to the bus sub-system, CAS2 could be
> > added to it, too.
> >
> 
> Yes I could imagine if we can have both CAS and CAS2, that could be
> interresting. But if it is only for CAS, well I maybe prefer 'll/sc'.

I really don't like state in hardware, that's a lot of problem in the
future : test, speed, speed up,...

nicO


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