Bug #56185 cannot use cpu id >255 in LockExecuteThreadToCPU

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;
  }

There is no workaround if any cpu has an id >255. The LockExecuteThreadToCPU clause will be silently ignored.

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

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

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)

Pushed to 7.0.18 and 7.1.7

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.

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)

Already documented in NDB-7.0.18, setting back to Closed.