Sam White comments

Results 90 comments of


                                            Sam White

CMK_LBDB_ON usages should be cleaned up

Should this be closed?

Study performance impact of avoiding doing array broadcasts via PE0

Another benefit would be that if the serialization number is made atomic, the comm thread can update the number without having to go through the PE 0 scheduler. Currently if...

Use C++ STL data structures in conv-conds.C

Needs some benchmarking and possibly performance optimization. Low priority for now so pushing off of 6.11

Verbs memory pool may leak pinned memory when message is deleted on a PE different from the one to which it was delivered

*Original date: 2017-09-06 18:25:22* --- Note that this is specific to a mempool in src/arch/verbs/machine-ibverbs.c, not the generic mempool that we have for GNI and Isomalloc in src/arch/util/mempool.{c,h}

Verbs memory pool may leak pinned memory when message is deleted on a PE different from the one to which it was delivered

*Original date: 2018-02-11 04:53:07* --- We don't really have a pressing need for this in 6.9.0, so deferring

Idle PEs compete with comm thread for node queue lock

*Original date: 2016-12-14 21:42:12* --- the new lockless PCQueue should alleviate this issue: ~~https://charm.cs.illinois.edu/gerrit/#/c/1302/~~ https://github.com/UIUC-PPL/charm/commit/ddf5c291d43655cef50bcb50bad0631cd2fcb818

Idle PEs compete with comm thread for node queue lock

*Original date: 2017-02-01 17:38:24* --- The new lockless queue (gerrit patch linked above) will address this issue, so re-assigning to Bilge as the owner of that patch.

Idle PEs compete with comm thread for node queue lock

*Original date: 2017-04-04 20:52:27* --- We are not planning on merging the lockless queue before the 6.8.0 release, since it is high risk this close to the release.

Idle PEs compete with comm thread for node queue lock

*Original date: 2018-01-29 12:47:27* --- This issue needs to be re-evaluated

Idle PEs compete with comm thread for node queue lock

*Original date: 2018-02-01 14:44:15* --- One proposed solution: instead of having one multi-producer/single-consumer queue per PE that the comm thread and all worker threads alike push work into, split that...