| Bug #56185 | cannot use cpu id >255 in LockExecuteThreadToCPU | ||
|---|---|---|---|
| Submitted: | 23 Aug 2010 11:04 | Modified: | 30 Aug 2010 14:22 |
| Reporter: | Axel Schwenke | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S3 (Non-critical) |
| Version: | mysql-5.1-telco-7.1 | OS: | Any |
| Assigned to: | Magnus Blåudd | CPU Architecture: | Any |
| Tags: | 5.1.44-ndb-7.1.4b | ||
[23 Aug 2010 11:16]
Axel Schwenke
There is no workaround if any cpu has an id >255. The LockExecuteThreadToCPU clause will be silently ignored.
[27 Aug 2010 12:06]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/116996
[27 Aug 2010 12:16]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/116999
[27 Aug 2010 13:34]
Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.47-ndb-7.0.18 (revid:magnus.blaudd@sun.com-20100827124935-ieqzj77a6gcfl0bx) (version source revid:magnus.blaudd@sun.com-20100827124935-ieqzj77a6gcfl0bx) (merge vers: 5.1.47-ndb-7.0.18) (pib:21)
[30 Aug 2010 9:09]
Magnus Blåudd
Pushed to 7.0.18 and 7.1.7
[30 Aug 2010 11:33]
Jon Stephens
Documented in the NDB-7.0.18 and 7.1.7 changelogs as follows:
The LockExecuteThreadToCPU configuration parameter was not handled
correctly for CPU ID values greater than 255.
Also noted in LockExecuteThreadToCPU parameter description in 5.1 Manual.
Closed.
[30 Aug 2010 12:46]
Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.47-ndb-7.0.19 (revid:magnus.blaudd@sun.com-20100830121448-grzbf4451bu6vndr) (version source revid:magnus.blaudd@sun.com-20100830112717-qw67sqzdsrphsbyj) (merge vers: 5.1.47-ndb-7.0.19) (pib:21)
[30 Aug 2010 14:22]
Jon Stephens
Already documented in NDB-7.0.18, setting back to Closed.

Description: The manual states that LockExecuteThreadToCPU accepts values in the range 0..64K. This is wrong. There is a limit 0..255. The bad thing: using a value of 256 or above will silently disable thread binding. How to repeat: [NDBD DEFAULT] MaxNoOfExecutionThreads=4 LockExecuteThreadToCPU=0,1,2,3 will yield in ndbmtd log: --- NDBMT: MaxNoOfExecutionThreads=4 NDBMT: workers=2 threads=2 ... thr: 4 tid: 4926 cpu: 3 OK CMVMI(0) thr: 0 tid: 4930 cpu: 2 OK DBTC(0) DBDIH(0) DBDICT(0) NDBCNTR(0) QMGR(0) NDBFS(0 ) TRIX(0) DBUTIL(0) thr: 3 tid: 4933 cpu: 1 OK PGMAN(2) DBACC(2) DBLQH(2) DBTUP(2) BACKUP(2) DBTUX(2 ) RESTORE(2) saving 0x7fbd1a680000 at 0x9c65d8 (0) thr: 1 tid: 4931 cpu: 2 OK BACKUP(0) DBLQH(0) DBACC(0) DBTUP(0) SUMA(0) DBTUX(0) TSMAN(0) LGMAN(0) PGMAN(0) RESTORE(0) DBINFO(0) PGMAN(5) 2010-08-23 12:57:45 [ndbd] INFO -- Start initiated (mysql-5.1.44 ndb-7.1.4) thr: 2 tid: 4932 cpu: 0 OK PGMAN(1) DBACC(1) DBLQH(1) DBTUP(1) BACKUP(1) DBTUX(1 ) RESTORE(1) --- however [NDBD DEFAULT] MaxNoOfExecutionThreads=4 LockExecuteThreadToCPU=0,1,2,256 yields: --- NDBMT: MaxNoOfExecutionThreads=4 NDBMT: workers=2 threads=2 2010-08-23 12:55:30 [ndbd] WARNING -- MaxNoOfExecutionThreads (4) > LockExecute ThreadToCPU count (0), this could cause contention ... thr: 3 tid: 4827 PGMAN(2) DBACC(2) DBLQH(2) DBTUP(2) BACKUP(2) DBTUX(2) RESTORE( 2) thr: 1 tid: 4825 BACKUP(0) DBLQH(0) DBACC(0) DBTUP(0) SUMA(0) DBTUX(0) TSMAN(0) LGMAN(0) PGMAN(0) RESTORE(0) DBINFO(0) PGMAN(5) thr: 4 tid: 4820 CMVMI(0) thr: 0 tid: 4824 DBTC(0) DBDIH(0) DBDICT(0) NDBCNTR(0) QMGR(0) NDBFS(0) TRIX(0) DBUTIL(0) --- notes: - there is a warning about 0 members in the LockExecuteThreadToCPU list - the kernel threads are not bound to cpus Suggested fix: The limit should be increased and properly documented. It seems Solaris uses a big sparse array for cpu core ids. I.e. on a 4-processor, 8-core Sun Fire E2900 the cores are numbered 0, 1, 2, 3, 512, 513, 514, 515. Values out of bound should be reported appropriately. Certainly a value out of bound should not silently disable this feature. kernel/vm/Configuration.hpp: ... #define NDB_CPU_MASK_SZ 256 kernel/vm/Configuration.cpp: ... void Configuration::executeLockCPU(Uint32 value) { if (value >= NDB_CPU_MASK_SZ) { value = NO_LOCK_CPU; }