io_setup() makes the ring at least 4 events per possible CPU of the
node. The ring is mapped into the task memory, and CRIU restores it with
io_setup() and moves the new mapping to the address of the old one, so
it needs a ring of the same size. On a node with more possible CPUs it
gets a bigger ring, and the restore fails. E.g. io_setup(1) makes a
ring of one page, 127 events, on 4 CPUs, and of two pages, 255 events,
on 16 CPUs.

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
up to pages: they don't depend on the node, and the queue depth CRIU
estimates from the dumped ring already offsets them, so the restore gets
the ring of the dumped size.

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.

https://virtuozzo.atlassian.net/browse/VSTOR-154129

Feature: ve: CRIU support
Signed-off-by: Pavel Tikhomirov <[email protected]>
---
 fs/aio.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/aio.c b/fs/aio.c
index 901cb622fe2c4..6e303e6612b6c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -761,8 +761,13 @@ static struct kioctx *ioctx_alloc(unsigned nr_events)
         * and unavailable, double nr_events so userspace sees what they
         * expected: additionally, we move req_batch slots to/from percpu
         * counters at a time, so make sure that isn't 0:
+        *
+        * CRIU restores a ring with io_setup() and needs the size it had on
+        * dump, which can be below the minimum of this node due to the CPU
+        * heuristic below, so skip the heuristic on restore.
         */
-       nr_events = max(nr_events, num_possible_cpus() * 4);
+       if (ve_is_super(ve) || !ve->is_pseudosuper)
+               nr_events = max(nr_events, num_possible_cpus() * 4);
        nr_events *= 2;
 
        /* Prevent overflows */

-- 
2.56.0

_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to