[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eece1309-4c1e-909a-22ea-3db31ad7a1da@gmail.com>
Date: Fri, 17 Sep 2021 09:56:26 +0800
From: brookxu <brookxu.cn@...il.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: tj@...nel.org, lizefan.x@...edance.com, hannes@...xchg.org,
vipinsh@...gle.com, corbet@....net, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 2/3] misc_cgroup: remove error log to avoid log flood
Thanks for your time.
Michal Koutný wrote on 2021/9/17 1:57 上午:
> On Wed, Sep 15, 2021 at 10:18:50AM +0800, brookxu <brookxu.cn@...il.com> wrote:
>> In scenarios where containers are frequently created and deleted,
>> a large number of error logs maybe generated. This log provides
>> less information, we can get more detailed info from misc.events.
>
> IIUC, the log provides equal information (with persistence), no?
>
>> diff --git a/kernel/cgroup/misc.c b/kernel/cgroup/misc.c
>> index 4b2b492..fe3e8a0 100644
>> --- a/kernel/cgroup/misc.c
>> +++ b/kernel/cgroup/misc.c
>> @@ -157,13 +157,6 @@ int misc_cg_try_charge(enum misc_res_type type, struct misc_cg *cg,
>> new_usage = atomic_long_add_return(amount, &res->usage);
>> if (new_usage > READ_ONCE(res->max) ||
>> new_usage > READ_ONCE(misc_res_capacity[type])) {
>> - if (!res->failed) {
>> - pr_info("cgroup: charge rejected by the misc controller for %s resource in ",
>> - misc_res_name[type]);
>> - pr_cont_cgroup_path(i->css.cgroup);
>> - pr_cont("\n");
>> - res->failed = true;
>> - }
>
> As I argued previously, reporting this as "in" `i` cgroup instead
> of `cg` is not that useful and equivalent to the misc.events:*.max now,
> so the drop is appropriate.
>
> The change/patch is OK,
> Reviewed-by: Michal Koutný <mkoutny@...e.com>
>
> The commit message might be fixed (if you agree with remark).
Yeah, maybe we should make it more clearly, What do you think of
the commit below:
In scenarios where containers are frequently created and deleted,
a large number of error logs maybe generated. The logs only show
which node is about to go over the max limit, not the node which
resource request failed. As misc.event has provided relevant
information, maybe we can remove this log.
>
Powered by blists - more mailing lists