on 03/06/2012 12:54 Attilio Rao said the following: > 2012/6/3 Andriy Gapon <[email protected]>: >> on 03/06/2012 00:39 Attilio Rao said the following: >>> The first thing to consider is that right now we only have 2 states >>> for CPUs: started and stopped. These states are controlled by >>> started_cpus and stopped_cpus masks respectively. It seems you really >>> want to add an intermediate level among the 2 where you have: started >>> -> suspended -> started -> suspended ... -> stopped and you need to >>> expand the mechanism for dealing with started and stopped cpus to do >>> that. I'm pretty sure this will be very helpful also for other >>> architectures that want to do the same. >> >> As the first thing I must admit that I haven't looked at the patch :-) >> >> >> But really I don't see why we need to differentiate between stopped and >> suspended state as both of them ultimately mean exactly the same thing - CPUs >> are spinning on some condition (and they are in a well-defined place and >> state). > > This is debeatable and I'm not sure I agree. > At some point we may want to implement CPU on-the-fly suspension for > CPUs which is a different event than "stopping" (where stopping will > be "permanent stopping" and suspending will be "possible to recover > suspension").
Right, but that should operate on the level above the current code. I.e. first stop all slave CPUs, than set state of a target CPU (which includes global view of that state), then resume all other CPUs. > The important thing about this is that we need to expand our model in > a way that it makes simple to add more states to the CPUs than simple > started/stopped. Right now we don't have any architecture for this in > place. I can't disagree with this, but I think that the current IPI-to-stop code is not a place for that. It's too low level. >> My view of how this should work is: >> - there can be only one master CPU that controls all other (slave) CPUs >> - the master sets entry and exit hooks >> - the master signals slaves to enter the stop state >> - the slaves execute the enter hook and start spinning on the release >> condition >> - the master does whatever it wants to do in this special system state >> - the master signals the slaves to resume >> - the slave exit the spin loop and execute the exit hook >> >> We have almost all of this in place. Only now we have different IPIs and >> different IPI handlers to do the job (cpustop_handler and >> cpususpend_handler). >> I think that the hooks model should be more universal. > > For hook you mean like a rendezvous handler? I'm not sure I understand > otherwise. Maybe, perhaps. I meant just a couple of function pointers. cpustop_restartfunc seems to be a better analogy. >> In my opinion, what really would deserve a completely independent path is the >> hard-stop case. As this can be invoked nested to the other cases. E.g. >> exotic >> situations like a breakpoint or a trap or a panic in the suspend or the >> normal >> stop code paths. > > What I'm really interested is expanding our model in a way that it can > handle multiple CPU states. Then it is just a matter of adding the > right states and it is all trivial work. > > And however, as already mentioned, I'm not sure I would assimilate > suspended = stopped. -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
