Questions about TSX

Questions about TSX

Аватар пользователя Dmitry Vyukov
Hi,

> 8.3.5RTM Abort Status Definition

Feedback and introspection seem to be critical for such systems; is it possible to get to know as to whether the abort was caused by a bad instruction (can't be executed in transactions at all, can't be executed in transactions on this particular processor) or by a memory protection fault (access to NULL), etc? It also would be useful to obtain PC and ADDR associated with abort. > 8.3.6RTM Memory Ordering >A successful RTM commit causes all memory operations in the RTM region to appear >to execute atomically. A successfully committed RTM region consisting of an XBEGIN >followed by an XEND, even with no memory operations in the RTM region, has the >same ordering semantics as a LOCK prefixed instruction. I am curious what is the rationale behind that. Does it mean that that adds several dozens of cycles to each trx? If I need MFENCE I can put it after a trx manually. What are approximate sizes of read/write sets? Are we talking about like 4 cache lines? Or 128 cache lines? That critically affects what can be implemenmted with TSX. TIA

All about lock-free algorithms, multicore, scalability, parallel computing and related topics: http://www.1024cores.net
8 сообщений / 0 новое
Последнее сообщение
Пожалуйста, обратитесь к странице Уведомление об оптимизации для более подробной информации относительно производительности и оптимизации в программных продуктах компании Intel.
Аватар пользователя Sergey Kostrov
Quoting Dmitriy Vyukov Hi,

> 8.3.5RTM Abort Status Definition

...is it possible to get to know as to whether the abort was caused by a bad instruction (can't be executed in transactions at all, can't be executed in transactions on this particular processor) or by a memory protection fault (access to NULL), etc?...

Could you use an exception handler? If Yes,an exception code could help to understand what really happened.
For example:

...
0x80000001 - Guard Page Violation
0xC0000005 - Access Violation
0xC0000006 - In Page Error
0xC000001D - Illegal Instruction
...

Аватар пользователя jimdempseyatthecove

>>Feedback and introspection seem to be critical for such systems; is it possible to get to know as to whether the abort was caused by a bad instruction (can't be executed in transactions at all, can't be executed in transactions on this particular processor) or by a memory protection fault (access to NULL), etc?

If you write the abort path correctly the memory protection fault should be exposed there.

For "bad instruction" I think this warrants a status bit (one of the remaining 23:6 bits in eax/rax).

However, even without this bit you can still write initialization code to test for support. Example, init code run by one thread testsfunction with RTM once or several times,if function always aborts then assume it will never succeed, and therefore set flag or change function dispatchto usealternate pathwhich uses older lock/unlock structure.

--- revision ---

If an unsupported (bad) instruction occures (say in the test code) bit 1 should not be set (indicating retry will not succeed)

Jim Dempsey

www.quickthreadprogramming.com
Аватар пользователя jimdempseyatthecove

TSX feature request/query

Consider a processor, say 8 core with HT (16 threads).

Consider maskable interrupts that are not masked OFF.

Any one of these hardware threads could acquire the responsibility of servicing the maskable interrupt.
It would be unfortunate for a hardware thread within an RTM to service the interrupt, should at the time of the interrupt there be a thread (not masked out) that is capable of servicing the interrupt and which is not in RTM.

The feature request is for the selection chriteria as to which thread processes the interrupt first applies to threads not in RTM. Should the case be all threads in RTM then the preferred choice would be the last thread to enter RTM. This feature would conserve on number of retries.

Jim Dempsey

www.quickthreadprogramming.com
Аватар пользователя Dmitry Vyukov

I believe that TSX suppresses all relevant exceptions. By "bad instruction" I meant not an illegal instruction, but an instruction that can't be executed in a transaction (unconditionally causes it to abort).

All about lock-free algorithms, multicore, scalability, parallel computing and related topics: http://www.1024cores.net
Аватар пользователя Dmitry Vyukov

>If an unsupported (bad) instruction occures (say in the test code) bit 1 should not be set (indicating retry will not succeed) Well, yes, it should be enough to dynamically dispatch to another code path. But it may be not enough for human analysis of what happens and why it happens and how to avoid aborts.

All about lock-free algorithms, multicore, scalability, parallel computing and related topics: http://www.1024cores.net
Аватар пользователя Roman Dementiev (Intel)

Hi,

There is an Intel Developer Forum 2012 presentation on Intel(r) Transactional Synchronization Extensions discussing implementation details. The slides can be downloaded in the technical session catalog: https://intel.activeevents.com/sf12/scheduler/catalog.do or http://intel.com/go/idfsessions (session ARCS004).

Best regards,
Roman

Аватар пользователя Roman Dementiev (Intel)

Зарегистрируйтесь, чтобы оставить комментарий.