From: Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
To: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH VZ10 v8 6/7] ve: Introduce per-VE failcount
Date: Mon, 14 Sep 2026 09:35:54 +0000 [thread overview]
Message-ID: <178937855430.982024.14476775263342989570.b4-review@b4> (raw)
In-Reply-To: <f1cc00374e7290a70a359b760e6255e280d8e5a7.1788989664.git.vladimir.riabchun@virtuozzo.com>
> It may be useful to have a history of resource limit hits for every VE,
> this may simplify debugging and provide some information about the
> resources usage.
>
> This information is provided by ve.failcount file, any write to it
> resets all failcounts.
>
> To add a new failcounter we need to create a new atomic_t field
> name_failcount in ve structure and add a new VE_FC_ENTRY in
> ve_failcounts array.
>
> One change, unrelated to failcounts: aio fields are now initialized
> in ve0.
>
> https://virtuozzo.atlassian.net/browse/VSTOR-135520
>
> Feature: per-ve failcounters
> Signed-off-by: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
>
> diff --git a/fs/aio.c b/fs/aio.c
> index cb63416af135..4ae06bcd47f2 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -814,6 +814,7 @@ static struct kioctx *ioctx_alloc(unsigned nr_events)
> spin_lock(&ve->aio_nr_lock);
> if (ve->aio_nr + ctx->max_reqs > ve->aio_max_nr ||
> ve->aio_nr + ctx->max_reqs < ve->aio_nr) {
> + ve_failcount_inc(ve, aio);
> spin_unlock(&ve->aio_nr_lock);
> err = -EAGAIN;
> goto err_ctx;
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 1d6e66cd7174..ea01664ff5f2 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3380,6 +3380,8 @@ static inline int ve_try_reserve_mount(struct ve_struct *ve)
>
> if (ret)
> get_ve(ve);
> + else
> + ve_failcount_inc(ve, mnt);
> return ret;
> }
>
> diff --git a/include/linux/ve.h b/include/linux/ve.h
> index fabc608e31f5..065129b42768 100644
> --- a/include/linux/ve.h
> +++ b/include/linux/ve.h
> @@ -80,12 +80,15 @@ struct ve_struct {
> struct kmapset_key proc_perms_key;
>
> atomic_t netns_avail_nr;
> + atomic_t netns_failcount;
> int netns_max_nr;
>
> atomic_t netif_avail_nr;
> + atomic_t netif_failcount;
> int netif_max_nr;
>
> atomic_t bpf_prog_avail_nr;
> + atomic_t bpf_prog_failcount;
> int bpf_prog_max_nr;
>
> atomic64_t _uevent_seqnum;
> @@ -94,6 +97,7 @@ struct ve_struct {
>
> atomic_t arp_neigh_nr;
> atomic_t nd_neigh_nr;
> + atomic_t neigh_tbl_failcount;
> unsigned long meminfo_val;
>
> /*
> @@ -102,6 +106,7 @@ struct ve_struct {
> * other containers.
> */
> atomic_t mnt_avail_nr; /* number of available VE mounts */
> + atomic_t mnt_failcount;
> int mnt_max_nr;
>
> #ifdef CONFIG_COREDUMP
> @@ -129,6 +134,7 @@ struct ve_struct {
> spinlock_t aio_nr_lock;
> unsigned long aio_nr;
> unsigned long aio_max_nr;
> + atomic_t aio_failcount;
> #endif
> struct vfsmount *devtmpfs_mnt;
> };
> @@ -151,6 +157,16 @@ extern int nr_ve;
> #define BPF_PROG_MAX_NR_DEFAULT 256 /* number of loaded BPF progs per-VE */
> #define MNT_MAX_NR_DEFAULT 4096 /* number of mounts per-VE */
>
> +#define ve_failcount_inc(ve, name) \
> +do { \
> + struct ve_struct *__ve = (ve); \
> + \
> + atomic_inc(&__ve->name##_failcount); \
> + ve_pr_warn_ratelimited(VE_LOG_BOTH, "CT%s: hits the " #name \
> + " limit, see the '" #name "' counter in ve.failcount " \
> + "of the container's ve cgroup\n", ve_name(__ve)); \
If this is called in softirq context for example like neigh_alloc it
will print into ve of whatever task was just interrupted. So a random ve
will receive this warning into its dmesg. I don't think this is good.
--
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-09-14 9:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 21:35 [Devel] [PATCH VZ10 v8 0/7] Add per-VE failcount support Vladimir Riabchun
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 1/7] ve/ve.{h, c}: Farewell to spaces as indents Vladimir Riabchun
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 2/7] ve/fs: Rework per-ve mount count Vladimir Riabchun
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 3/7] selftests/ve: Update ve_ns_owner_test Vladimir Riabchun
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 4/7] ve: Move from global VE mounts limit to per-VE limit Vladimir Riabchun
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 5/7] ve/ve.c: Generate VE resource accessors using macros Vladimir Riabchun
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 6/7] ve: Introduce per-VE failcount Vladimir Riabchun
2026-09-14 9:35 ` Vasileios Almpanis [this message]
2026-09-09 21:35 ` [Devel] [PATCH VZ10 v8 7/7] selftests/ve: Add mount accounting selftest Vladimir Riabchun
2026-09-14 9:35 ` Vasileios Almpanis
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=178937855430.982024.14476775263342989570.b4-review@b4 \
--to=vasileios.almpanis@virtuozzo.com \
--cc=devel@openvz.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox