[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64cb078b-d2e7-417f-8125-b38d423163ce@intel.com>
Date: Thu, 9 Nov 2023 06:26:08 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Byungchul Park <byungchul@...com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Cc: kernel_team@...ynix.com, akpm@...ux-foundation.org,
ying.huang@...el.com, namit@...are.com, xhao@...ux.alibaba.com,
mgorman@...hsingularity.net, hughd@...gle.com, willy@...radead.org,
david@...hat.com, peterz@...radead.org, luto@...nel.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com
Subject: Re: [v4 0/3] Reduce TLB flushes under some specific conditions
On 11/8/23 20:59, Byungchul Park wrote:
> Can you believe it? I saw the number of TLB full flush reduced about
> 80% and iTLB miss reduced about 50%, and the time wise performance
> always shows at least 1% stable improvement with the workload I tested
> with, XSBench. However, I believe that it would help more with other
> ones or any real ones. It'd be appreciated to let me know if I'm missing
> something.
I see that you've moved a substantial amount of code out of arch/x86.
That's great.
But there doesn't appear to be any improvement in the justification or
performance data. The page flag is also here, which is horribly frowned
upon. It's an absolute no-go with this level of justification.
I'd really suggest not sending any more of these out until those issues
are rectified. I know I definitely won't be reviewing them in this state.
Powered by blists - more mailing lists