-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/22/2013 02:30 AM, Albert ARIBAUD wrote:
Hi Scott,
Perhaps it could be, or the application could be altered to release secondary cores through the spin table. I don't think that excuses a situation where some ways of putting a blob of bytes into RAM flush the cache (to the extent the architecture requires it for the blob of bytes to be executable) and others don't, and there's no way to do it manually.
AFAIU there is.
Would you remove the "go" command entirely? I think that would be a mistake.
I do not see why you are talking about removing the "go" command. In the 'worst' scenario (from an effort perspective), it would have to be do a flush and possibly cache disable before branching to the payload; in the 'best' scenario, it needs not be modified at all.
It seems like we're going around and around with one point not being addressed. When using 'go', how do you know the size to flush? And since Scott is talking about performance testing apps, the cache should not be disabled (unless we expect all standalone apps to enable the cache, in which case we need to provide something in the jump table to make that easy and document this change).
- -- Tom