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 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.