[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4847C6FE-429D-4619-9200-6CE7C84B5386@fb.com>
Date: Mon, 29 Aug 2022 20:19:26 +0000
From: "Alex Zhu (Kernel)" <alexlzhu@...com>
To: Zi Yan <ziy@...dia.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
Matthew Wilcox <willy@...radead.org>,
"hannes@...xchg.org" <hannes@...xchg.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"riel@...riel.com" <riel@...riel.com>,
Kernel Team <Kernel-team@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 1/3] mm: add thp_utilization metrics to debugfs
> On Aug 26, 2022, at 5:11 PM, Zi Yan <ziy@...dia.com> wrote:
>
> On 25 Aug 2022, at 17:30, alexlzhu@...com wrote:
>
> How large is the memory? Just wonder the scanning speed.
> Also, it might be better to explicitly add the time unit, second,
> in the output.
The size of memory was 65GB on the test machine I obtained these
numbers on. I’ll take note of adding the time unit. Thanks!
> Is it possible to use cache-bypassing read to avoid cache
> pollution? You are scanning for 256*2M at a time. Wouldn’t that
> wipe out all the useful data in the cache?
I have only found non-temporal writes in arch/x86/, not non-temporal reads (with MOVNTDQA). I suppose we should figure out why nobody ever bothered using non-temporal reads on x86 before trying to make this code use them.
A quick search of the internet suggests they non-temporal reads are not being used on x86 because people could not show a performance improvement by using them, but maybe somebody here has more insight?
Powered by blists - more mailing lists