[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877dg0wcrr.fsf@linux.intel.com>
Date: Wed, 01 Sep 2021 08:12:24 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Feng Tang <feng.tang@...el.com>
Cc: Michal Koutn?? <mkoutny@...e.com>,
Johannes Weiner <hannes@...xchg.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
andi.kleen@...el.com, kernel test robot <oliver.sang@...el.com>,
Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...e.com>,
Shakeel Butt <shakeelb@...gle.com>,
Balbir Singh <bsingharora@...il.com>,
Tejun Heo <tj@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
kernel test robot <lkp@...el.com>,
"Huang\, Ying" <ying.huang@...el.com>,
Zhengjun Xing <zhengjun.xing@...ux.intel.com>
Subject: Re: [mm] 2d146aa3aa: vm-scalability.throughput -36.4% regression
Feng Tang <feng.tang@...el.com> writes:
>
> Yes, the tests I did is no matter where the 128B padding is added, the
> performance can be restored and even improved.
I wonder if we can find some cold, rarely accessed, data to put into the
padding to not waste it. Perhaps some name strings? Or the destroy
support, which doesn't sound like its commonly used.
-Andi
Powered by blists - more mailing lists