I won't apply this version, please send v2 with the changes below.
On Fri, 13 Nov 2026 16:08:44 +0100, Pavel Tikhomirov wrote:
> After a migration to a node with more possible CPUs an AIO context can
> be slightly less reliable: io_submit() can return EAGAIN before the ring
> is full, while free slots sit in the per-CPU caches of other CPUs.
Item 1 of the cover letter reply: keep a restored small ring out of
the per-CPU slot caches, or state the real bound here.
Why: the doubling relies on the heuristic: with at least 8 events per
possible CPU, the slots cached on other CPUs stay below half the ring.
A restored ring has no such floor. req_batch drops to 1, and
put_reqs_available() leaves one slot on every CPU a completion runs on,
which only a submit from that CPU takes back.
A one-page ring dumped on 4 CPUs comes from io_setup() of up to 62
events and has 126 usable slots. Restored on a big node,
io_submit() returns EAGAIN with fewer requests in flight than the
application asked for once completions have run on more than 64 other
CPUs. Once 126 CPUs hold a slot, it returns EAGAIN with nothing in
flight, and an application that then waits for a completion hangs.
Before the patch this migration failed cleanly and the CT stayed on
the source node.
> Skip the CPU heuristic while the VE is pseudosuper, which it is only for
> the restore. Keep the other adjustments, the doubling and the rounding
Item 2 of the cover letter reply: the VE is also pseudosuper during
every CT start.
Why: libvzctl do_env_create() sets ve.pseudosuper on every start, and
the CT's first task clears it just before it execs init. vzctl runs no
AIO in that window, so the code is fine, but the message and the
comment ("skip the heuristic on restore") say otherwise.
> gets a bigger ring, and the restore fails. E.g. io_setup(1) makes a
Item 3 of the cover letter reply: say what the user sees.
Why: CRIU's restore_aio_ring() compares the new ring with the dumped
one, reports "wrong aio" and the migration is aborted.
--
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
