public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Waiman Long <llong@redhat.com>,
	cgroups@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, Josef Bacik <josef@toxicpanda.com>,
	Jens Axboe <axboe@kernel.dk>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH 1/9] cgroup/cpuset-v1: Add deprecation warnings to sched_load_balance and memory_pressure_enabled
Date: Wed, 5 Mar 2025 08:39:49 -1000	[thread overview]
Message-ID: <Z8iadfcPxgamx9CC@slm.duckdns.org> (raw)
In-Reply-To: <5bw7yc6bacojk2i2ikhlmf2skfiix6t3ipchbnvyfttmyh644j@iyquxeuyapd7>

Hello,

On Wed, Mar 05, 2025 at 11:12:21AM +0100, Michal Koutný wrote:
> On Tue, Mar 04, 2025 at 08:04:06AM -1000, Tejun Heo <tj@kernel.org> wrote:
> > I'm apprehensive about adding warning messages which may be triggered
> > consistently without anything end users can do about them.
> 
> That means you'd distinguish RE (replacement exists) vs DN (dropped as
> non-ideal) categories?

I don't think I am. I'm just concerned about emitting warn messages on every
boot without users being able to do anything about them.

> > I think that deprecation messages, unless such deprecation is
> > immediate and would have direct consequences on how the system can be
> > used, should be informational.
> 
> I could subscribe to that if there weren't so many other places to
> evaluate:
>   $ git grep -i "pr_warn.*deprec" torvalds/master --  | wc -l
>   62
>   $ git grep -i "pr_info.*deprec" torvalds/master --  | wc -l
>   2
> 
> So is the disctinction worth the hassle?

Well, not all deprecations are the same. If users are stuck on cgroup1, they
can be really stuck - there can be a tall stack of software with
dependencies that users can't do much about, at least not immediately. We
will deprecate cgroup1 but this is going to be a long stretched out process
at the end of which we should be fairly comfortable in stating that there
aren't major users left which are stuck on cgroup1.

It's almost certain that that future won't arrive in, say, three years. Five
years may be too ambitious too but let's say that at that point we are
relatively sure that most platforms have moved on (but there may still be
users on older versions of those platforms). Maybe it'd make sense to
increase the deprecation warning temperature by then to warn and drain
existing users and maybe after a few years we'd actually be able to drop
cgroup1 support.

So, I don't want to be emitting warnings on every boot for the good part of
a decade on every boot for those users. Doing so feels silly and annoying to
me. Let's inform that it's coming down the pipeline but I personally don't
want to be warned by something that's close to a decade out.

Thanks.

-- 
tejun

  reply	other threads:[~2025-03-05 18:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04 15:37 [PATCH 0/9] cgroup v1 deprecation warnings Michal Koutný
2025-03-04 15:37 ` [PATCH 1/9] cgroup/cpuset-v1: Add deprecation warnings to sched_load_balance and memory_pressure_enabled Michal Koutný
2025-03-04 16:19   ` Waiman Long
2025-03-04 16:52     ` Tejun Heo
2025-03-04 17:10       ` Michal Koutný
2025-03-04 17:33         ` Waiman Long
2025-03-04 18:04           ` Tejun Heo
2025-03-05 10:12             ` Michal Koutný
2025-03-05 18:39               ` Tejun Heo [this message]
2025-03-04 15:37 ` [PATCH 2/9] cgroup/cpuset-v1: Add deprecation warnings to memory_spread_page and memory_spread_slab Michal Koutný
2025-03-04 15:37 ` [PATCH 3/9] cgroup/blkio: Add deprecation warnings to reset_stats Michal Koutný
2025-03-04 15:37 ` [PATCH 4/9] cgroup: Print warning when /proc/cgroups is read on v2-only system Michal Koutný
2025-03-04 16:55   ` Tejun Heo
2025-03-05 10:17     ` Michal Koutný
2025-03-05 16:27       ` Waiman Long
2025-03-04 15:37 ` [PATCH 5/9] RFC cgroup/cpuset-v1: Add deprecation warnings to mem_exclusive and mem_hardwall Michal Koutný
2025-03-04 15:37 ` [PATCH 6/9] RFC cgroup/cpuset-v1: Add deprecation warnings to memory_migrate Michal Koutný
2025-03-04 15:37 ` [PATCH 7/9] RFC cgroup/cpuset-v1: Add deprecation warnings to sched_relax_domain_level Michal Koutný
2025-03-04 15:38 ` [PATCH 8/9] cgroup: Update file naming comment Michal Koutný
2025-03-04 15:38 ` [PATCH 9/9] blk-cgroup: Simplify policy files registration Michal Koutný

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=Z8iadfcPxgamx9CC@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=mkoutny@suse.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