Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Tue, 31 Oct 2023 07:55:48 +0900
From:   Byungchul Park <byungchul@sk.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        kernel_team@skhynix.com, akpm@linux-foundation.org,
        ying.huang@intel.com, namit@vmware.com, xhao@linux.alibaba.com,
        mgorman@techsingularity.net, hughd@google.com, willy@infradead.org,
        david@redhat.com, peterz@infradead.org, luto@kernel.org,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com
Subject: Re: [v3 0/3] Reduce TLB flushes under some specific conditions
Message-ID: <20231030225548.GB900@system.software.com>
References: <20231030072540.38631-1-byungchul@sk.com>
 <08c82a91-87d1-42c7-93c4-4028f3725340@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08c82a91-87d1-42c7-93c4-4028f3725340@intel.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Mon, Oct 30, 2023 at 10:55:07AM -0700, Dave Hansen wrote:
> On 10/30/23 00:25, Byungchul Park wrote:
> > I'm suggesting a mechanism to reduce TLB flushes by keeping source and
> > destination of folios participated in the migrations until all TLB
> > flushes required are done, only if those folios are not mapped with
> > write permission PTE entries at all. I worked Based on v6.6-rc5.
> 
> There's a lot of common overhead here, on top of the complexity in general:
> 
>  * A new page flag
>  * A new cpumask_t in task_struct
>  * A new zone list
>  * Extra (temporary) memory consumption
> 
> and the benefits are ... "performance improved a little bit" on one
> workload.  That doesn't seem like a good overall tradeoff to me.
> 
> There will certainly be workloads that, before this patch, would have
> little or no memory pressure and after this patch would need to do reclaim.

'if (gain - cost) > 0 ?'" is a difficult problem. I think the followings
are already big benefit in general:

	1. big reduction of IPIs #
	2. big reduction of TLB flushes #
	3. big reduction of TLB misses #

Of course, I or we need to keep trying to see a better number in
end-to-end performance.

> Also, looking with my arch/x86 hat on, there's really nothing
> arch-specific here.  Please try to keep stuff out of arch/x86 unless
> it's very much arch-specific.

Okay. I will try to keep it out of arch code. I should give up an
optimization that can be achieved by working on arch code tho.

	Byungchul