From: Alexey Kuznetsov <kuznet@virtuozzo.com>
To: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
Cc: devel@openvz.org, Liu Kui <kui.liu@virtuozzo.com>,
azaitsev@virtuozzo.com
Subject: Re: [Devel] [PATCH hci-8.1] fs/fuse kio: start connect once per rpc_queue_work batch
Date: Tue, 22 Sep 2026 21:12:51 +0800 [thread overview]
Message-ID: <CAMrnHh4o4tMQxqDfizz41YHNZ+KVVvA4JK0jRdxEsvJJmkhZLQ@mail.gmail.com> (raw)
In-Reply-To: <441bdbcd-d5fd-4708-afa9-2d82ddbcb401@virtuozzo.com>
Hello!
On Tue, Sep 22, 2026 at 7:41 PM Vladimir Riabchun
<vladimir.riabchun@virtuozzo.com> wrote:
> These were just my thoughts if we can heal the stuck thread with
> low effort. Seems like no - at least we need to drop these
> assertions.
I do not see any problems there. Well, except for too scary code.
If you see, elaborate, I could miss something.
> To prevent cases like the one below - inconsistent code state.
IMHO it prevents nothing. It just minimizes patch success. :-)
Is it correct that all these kludges are done to avoid stop machine?
Or is it still used? Sleeping states must be responsibility of patch maker,
protections based on traces are just useless, kernel simply cannot do it
by many reasons f.e. because of tail calls.
> Btw, I'm just curious, how iptables rule will help? It will tesspeed up pcs_rpc_connect?
Yes, almost infinitely. In the last case we had 16 dead rpcs, each has
queued 200000-300000
requests. Each connect waits for ~2sec. So, counting: it would take
~75 days to finish. :-)
With -j DROP they were processed faster than I started drgn to measure
the rate, some
seconds.
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-09-22 13:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 11:28 Liu Kui
2026-09-21 12:13 ` Alexey Kuznetsov
2026-09-21 20:52 ` Vladimir Riabchun
2026-09-21 21:17 ` Alexey Kuznetsov
2026-09-22 9:38 ` Vladimir Riabchun
2026-09-22 10:46 ` Alexey Kuznetsov
2026-09-22 11:36 ` Vladimir Riabchun
2026-09-22 13:12 ` Alexey Kuznetsov [this message]
2026-09-22 14:10 ` Vladimir Riabchun
2026-09-22 15:01 ` Alexey Kuznetsov
2026-09-22 15:19 ` Vladimir Riabchun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMrnHh4o4tMQxqDfizz41YHNZ+KVVvA4JK0jRdxEsvJJmkhZLQ@mail.gmail.com \
--to=kuznet@virtuozzo.com \
--cc=azaitsev@virtuozzo.com \
--cc=devel@openvz.org \
--cc=kui.liu@virtuozzo.com \
--cc=vladimir.riabchun@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.