summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/fs/tty
diff options
context:
space:
mode:
authorMichael Pratt <mpratt@google.com>2019-04-03 16:21:38 -0700
committerShentubot <shentubot@google.com>2019-04-03 16:22:43 -0700
commit4968dd1341a04e93557bdd9f4b4b83eb508e026d (patch)
tree50ef3c28ec24fad937f029f257cbe3338222445f /pkg/sentry/fs/tty
parent82529becaee6f5050cb3ebb4aaa7a798357c1cf1 (diff)
Cache ThreadGroups in PIDNamespace
If there are thousands of threads, ThreadGroupsAppend becomes very expensive as it must iterate over all Tasks to find the ThreadGroup leaders. Reduce the cost by maintaining a map of ThreadGroups which can be used to grab them all directly. The one somewhat visible change is to convert PID namespace init children zapping to a group-directed SIGKILL, as Linux did in 82058d668465 "signal: Use group_send_sig_info to kill all processes in a pid namespace". In a benchmark that creates N threads which sleep for two minutes, we see approximately this much CPU time in ThreadGroupsAppend: Before: 1 thread: 0ms 1024 threads: 30ms - 9130ms 4096 threads: 50ms - 2000ms 8192 threads: 18160ms 16384 threads: 17210ms After: 1 thread: 0ms 1024 threads: 0ms 4096 threads: 0ms 8192 threads: 0ms 16384 threads: 0ms The profiling is actually extremely noisy (likely due to cache effects), as some runs show almost no samples at 1024, 4096 threads, but obviously this does not scale to lots of threads. PiperOrigin-RevId: 241828039 Change-Id: I17827c90045df4b3c49b3174f3a05bca3026a72c
Diffstat (limited to 'pkg/sentry/fs/tty')
0 files changed, 0 insertions, 0 deletions