[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YZ5v2LZlpzHieq/+@dhcp22.suse.cz>
Date: Wed, 24 Nov 2021 18:01:12 +0100
From: Michal Hocko <mhocko@...e.com>
To: kernel test robot <oliver.sang@...el.com>
Cc: Shakeel Butt <shakeelb@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, Roman Gushchin <guro@...com>,
Muchun Song <songmuchun@...edance.com>,
Vasily Averin <vvs@...tuozzo.com>,
Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
lkp@...el.com, ying.huang@...el.com, feng.tang@...el.com,
zhengjun.xing@...ux.intel.com, fengwei.yin@...el.com
Subject: Re: [memcg, kmem] 58056f7750: hackbench.throughput 10.3%
improvement
On Wed 24-11-21 16:34:35, kernel test robot wrote:
>
>
> Greeting,
>
> FYI, we noticed a 10.3% improvement of hackbench.throughput due to commit:
>
>
> commit: 58056f77502f3567b760c9a8fc8d2e9081515b2d ("memcg, kmem: further deprecate kmem.limit_in_bytes")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
I am really surprised to see an improvement from this patch. I do not
expect your benchmarking would be using kmem limit. The above patch
hasn't really removed the page counter out of the picture so there
shouldn't be any real reason for performance improvement. I strongly
suspect this is just some benchmark artifact or unreliable evaluation.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists