On 08/22/2017 06:14 PM, kemi wrote:
> when performance is not important and when you want all tooling to work, you
> set:
>
> sysctl vm.strict_stats=1
>
> but if you can tolerate some possible tool breakage and some decreased
> counter precision, you can do:
>
> sysctl vm.strict_sta
On 2017年08月23日 05:22, Christopher Lameter wrote:
> Can we simple get rid of the stats or make then configurable (off by
> defaut)? I agree they are rarely used and have been rarely used in the past.
>
I agree that we can make numa stats as well as other stats items that are rarely
used configur
Christopher Lameter writes:
> Can we simple get rid of the stats or make then configurable (off by
> defaut)? I agree they are rarely used and have been rarely used in the past.
>
> Maybe some instrumentation for perf etc will allow
> similar statistics these days? Thus its possible to drop them?
Can we simple get rid of the stats or make then configurable (off by
defaut)? I agree they are rarely used and have been rarely used in the past.
Maybe some instrumentation for perf etc will allow
similar statistics these days? Thus its possible to drop them?
The space in the pcp pageset is preci
On 2017年08月15日 18:36, Jesper Dangaard Brouer wrote:
> On Tue, 15 Aug 2017 16:45:34 +0800
> Kemi Wang wrote:
>
>> Each page allocation updates a set of per-zone statistics with a call to
>> zone_statistics(). As discussed in 2017 MM submit, these are a substantial
>
On Tue, 15 Aug 2017 16:45:34 +0800
Kemi Wang wrote:
> Each page allocation updates a set of per-zone statistics with a call to
> zone_statistics(). As discussed in 2017 MM submit, these are a substantial
^^ should be "summit"
> source of overhead i
Each page allocation updates a set of per-zone statistics with a call to
zone_statistics(). As discussed in 2017 MM submit, these are a substantial
source of overhead in the page allocator and are very rarely consumed. This
significant overhead in cache bouncing caused by zone counters (NUMA
associ
7 matches
Mail list logo
