[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rep:[f-cpu] Hot issue : external LSU ?
- To: f-cpu@seul.org
- Subject: Re: Rep:[f-cpu] Hot issue : external LSU ?
- From: nico <nicolas.boulay@ifrance.com>
- Date: Sun, 01 Sep 2002 16:09:12 +0200
- Delivered-To: archiver@seul.org
- Delivered-To: f-cpu-outgoing@seul.org
- Delivered-To: f-cpu@seul.org
- Delivery-Date: Sun, 01 Sep 2002 09:45:29 -0400
- References: <200208301720.21e0@th00.opsion.fr> <003401c2505d$37cabf90$0100000a@ifurita> <3D6FD726.FC670D01@ifrance.com> <001501c2507a$fdc08500$0100000a@ifurita> <3D70D54C.22118A78@ifrance.com> <002101c25107$7979c6c0$0100000a@ifurita> <3D7124B2.D8AC6D9D@ifrance.com> <002601c25148$6366eca0$0100000a@ifurita> <3D71F4E9.F9D5E27C@ifrance.com> <000701c251b3$9b8a8ea0$0100000a@ifurita>
- Reply-To: f-cpu@seul.org
- Sender: owner-f-cpu@seul.org
Christophe Avoinne a écrit :
>
> Well let's and see. For the moment we haven't even a uniprocessor working so
> we should delay this issue until it comes necessary.
>
Yes and no. I strongly beleive that all is now decide which can be seen
by the user will be keep as is. So good definition should be find now.
> ----- Original Message -----
> From: "nico" <nicolas.boulay@ifrance.com>
> To: <f-cpu@seul.org>
> Sent: Sunday, September 01, 2002 1:07 PM
> Subject: Re: Rep:[f-cpu] Hot issue : external LSU ?
>
> > Imagine 32 node with Apache process&thread. In the worst case, you could
> > go in infinite loop, no ?
> >
>
> No, because there would always one which succeeds. If one succeeds, the
> others will have more chance to succeed too until all succeed. The laptime
> spent between 'll' and 'sc' is so ridiculous short compared with the rest
> that must be executed. Anyway, I see 'll/sc' as a way to do no blocking
> synchronistation, but not the only one.
If there is no entries deleted because there isn't enought room any more
in the dirty/lock bit LSU.
>
> > 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.
>
> Well a true CAS cycle would be more interesting. Such thing is possible ?
>
Yes, we just have to define it. It will be a mandatory feature of the
interconnect newtwork. Then this should be handel by the slaves devices
(the memory controller).
> > > 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 !
>
> No, you didn't understand me. Intra-cpu locking can be interesting if code
> just need to be executed in a uni-processor environment. That's all.
>
> Anyway, the uniprocessor wouldn't suffer from an external-LSU since it
> doesn't need to be present (behaves as if no-dirty bit checking always
> succeeds in that case) and you don't incur an io bus locking indeed.
>
> The external-LSU behaves exactly as an internal-LSU but it is shared between
> CPU. The only instant when you have a locktime is when several cpus tries to
> access meanwhile. But such a thing would happen for CAS too.
>
Yes, but the underlaying hardware isn't the same at all.
> > The external LSU means a set/unset for each access and that is a cost
> > for each memory access.
>
> The external LSU is only accessed when a inter-cpu locking is involved and
> is accessed as a cpu would access an internal LSU.
>
The external LSU is taking into account in ll/sc transaction but it
still there in all access (+if a normal load occure in a locked adresse
the lock bit must be cleared).
> > I really don't like state in hardware, that's a lot of problem in the
> > future : test, speed, speed up,...
>
> State ? I'm not sure there is any state with 'll/sc'.
>
If you set a bit, there is a state (lock/unlocked).
nicO
> ---
>
> I believe Whygee and Michael R. prefer 'll/sc' instructions against CAS
> instruction.
>
> ---
>
> I need to know the real format of your CAS.
>
> For me it should look something like :
>
> before : three registers contain an expected value, a value address and
> a new value
> after : one register contains the read value before writing
> or
> before : three registers contain an expected value, a value address and
> a new value
> after : one register contains a boolean value telling us if writing
> succeeds.
>
> Is such format possible with a CAS cycle ?
Yes, it is. We define buses also, so this kind of feature could be
imposed.
The 2 formats are possible but the first is more general.
>
> CAS2: geeek ! we need 6 registers instead of 3 ! of course we can decide to
> use pair of registers ( rN', rN^1). But I feel it isn't feasible.
Not if you "link" instruction. Remember if we lose some cycle here it's
not so hard.
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/