Skip to content

Use pidfd to monitor for process deletion instead of 100ms poll loop - #13952

Open
EtiennePerot wants to merge 1 commit into
google:masterfrom
EtiennePerot:waitforstopped-nopoll
Open

Use pidfd to monitor for process deletion instead of 100ms poll loop#13952
EtiennePerot wants to merge 1 commit into
google:masterfrom
EtiennePerot:waitforstopped-nopoll

Conversation

@EtiennePerot

Copy link
Copy Markdown
Collaborator

As expected, cuts ~100ms from runsc create + runsc delete cycle.

Doesn't make container startup faster, but for systems that maintain a constant number of idle sandboxes, this is a large difference in speed.

             │         old         │               new                   │
             │       sec/op        │   sec/op     vs base                │
CreateDelete           205.0m ± 4%   109.9m ± 8%  -46.39% (p=0.000 n=20)

As expected, cuts ~100ms from `runsc create` + `runsc delete` cycle.

Doesn't make container startup faster, but for systems that maintain a
constant number of idle sandboxes, this is a large difference in speed.

```
             │         old         │               new                   │
             │       sec/op        │   sec/op     vs base                │
CreateDelete           205.0m ± 4%   109.9m ± 8%  -46.39% (p=0.000 n=20)
```
@EtiennePerot
EtiennePerot requested a review from ayushr2 August 1, 2026 02:20
@milantracy

Copy link
Copy Markdown
Collaborator

How does creating and deleting help a pool of idle containers

, it literally doesn't have to create or delete containers unless it has to maintain some leaky buffer pattern

@EtiennePerot

Copy link
Copy Markdown
Collaborator Author

How does creating and deleting help a pool of idle containers

, it literally doesn't have to create or delete containers unless it has to maintain some leaky buffer pattern

A sandbox cannot be safely reused after having run untrusted code. So a system that tries to maintain a densely-packed "warm pool" of sandboxes must ensure that the same number of sandboxes are always running, and must therefore recreate a new one as soon as another exits.

Detecting that a sandbox has exited 100ms sooner means it can start the creation of a new sandbox 100ms earlier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants