* [LTP] numastats updates
@ 2014-04-03 10:45 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-03 10:45 UTC (permalink / raw)
To: linux-numa; +Cc: ltp-list
Hello!
In LTP we have a test - numa01.sh
(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/numa/numa01.sh)
In general, this script does something like:
* numastat > /tmp/before
* starts a binary with the specified numa memory policy using numactl
(or a like):
numactl --interleave=all get_some_memory_with_malloc_and_write_it
* `sleep` for few seconds
* numastat > /tmp/after
* compares /tmp/before and /tmp/after to check that the numa policy
was applied the right way
But the problem is that on a host with many NUMA nodes (8) the process
of updating that numastats statistics takes some time. Even 10 seconds
may be not enough. Therefore the test fails.
Is there a direct or indirect way to force the kernel to update the NUMA
statistics?
Thank you.
------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread* numastats updates
@ 2014-04-03 10:45 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-03 10:45 UTC (permalink / raw)
To: linux-numa; +Cc: ltp-list
Hello!
In LTP we have a test - numa01.sh
(https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/numa/numa01.sh)
In general, this script does something like:
* numastat > /tmp/before
* starts a binary with the specified numa memory policy using numactl
(or a like):
numactl --interleave=all get_some_memory_with_malloc_and_write_it
* `sleep` for few seconds
* numastat > /tmp/after
* compares /tmp/before and /tmp/after to check that the numa policy
was applied the right way
But the problem is that on a host with many NUMA nodes (8) the process
of updating that numastats statistics takes some time. Even 10 seconds
may be not enough. Therefore the test fails.
Is there a direct or indirect way to force the kernel to update the NUMA
statistics?
Thank you.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [LTP] numastats updates
2014-04-03 10:45 ` Stanislav Kholmanskikh
@ 2014-04-07 1:39 ` Andi Kleen
-1 siblings, 0 replies; 20+ messages in thread
From: Andi Kleen @ 2014-04-07 1:39 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: ltp-list, cl, linux-numa
On Thu, Apr 03, 2014 at 02:45:27PM +0400, Stanislav Kholmanskikh wrote:
> In LTP we have a test - numa01.sh (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/numa/numa01.sh)
numactl has similar tests
>
> In general, this script does something like:
> * numastat > /tmp/before
> * starts a binary with the specified numa memory policy using
> numactl (or a like):
> numactl --interleave=all get_some_memory_with_malloc_and_write_it
> * `sleep` for few seconds
> * numastat > /tmp/after
> * compares /tmp/before and /tmp/after to check that the numa policy
> was applied the right way
>
> But the problem is that on a host with many NUMA nodes (8) the process
> of updating that numastats statistics takes some time. Even 10 seconds
> may be not enough. Therefore the test fails.
>
> Is there a direct or indirect way to force the kernel to update the
> NUMA statistics?
Not currently. It depends on how much memory you have and subsequent
operations. I guess would need to add one.
-Andi
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: numastats updates
@ 2014-04-07 1:39 ` Andi Kleen
0 siblings, 0 replies; 20+ messages in thread
From: Andi Kleen @ 2014-04-07 1:39 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: linux-numa, ltp-list, cl
On Thu, Apr 03, 2014 at 02:45:27PM +0400, Stanislav Kholmanskikh wrote:
> In LTP we have a test - numa01.sh (https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/numa/numa01.sh)
numactl has similar tests
>
> In general, this script does something like:
> * numastat > /tmp/before
> * starts a binary with the specified numa memory policy using
> numactl (or a like):
> numactl --interleave=all get_some_memory_with_malloc_and_write_it
> * `sleep` for few seconds
> * numastat > /tmp/after
> * compares /tmp/before and /tmp/after to check that the numa policy
> was applied the right way
>
> But the problem is that on a host with many NUMA nodes (8) the process
> of updating that numastats statistics takes some time. Even 10 seconds
> may be not enough. Therefore the test fails.
>
> Is there a direct or indirect way to force the kernel to update the
> NUMA statistics?
Not currently. It depends on how much memory you have and subsequent
operations. I guess would need to add one.
-Andi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-07 1:39 ` Andi Kleen
@ 2014-04-07 15:47 ` Christoph Lameter
-1 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-07 15:47 UTC (permalink / raw)
To: Andi Kleen; +Cc: ltp-list, linux-numa
On Mon, 7 Apr 2014, Andi Kleen wrote:
> > * starts a binary with the specified numa memory policy using
> > numactl (or a like):
> > numactl --interleave=all get_some_memory_with_malloc_and_write_it
> > * `sleep` for few seconds
> > * numastat > /tmp/after
> > * compares /tmp/before and /tmp/after to check that the numa policy
> > was applied the right way
> >
> > But the problem is that on a host with many NUMA nodes (8) the process
> > of updating that numastats statistics takes some time. Even 10 seconds
> > may be not enough. Therefore the test fails.
> >
> > Is there a direct or indirect way to force the kernel to update the
> > NUMA statistics?
>
> Not currently. It depends on how much memory you have and subsequent
> operations. I guess would need to add one.
The kernel vm statistics are brought up to date with the default
settings every 2 seconds.
The interval is controlled via /proc/sys/vm/stat_interval
Check the value that you have setup there.
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: numastats updates
@ 2014-04-07 15:47 ` Christoph Lameter
0 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-07 15:47 UTC (permalink / raw)
To: Andi Kleen; +Cc: Stanislav Kholmanskikh, linux-numa, ltp-list
On Mon, 7 Apr 2014, Andi Kleen wrote:
> > * starts a binary with the specified numa memory policy using
> > numactl (or a like):
> > numactl --interleave=all get_some_memory_with_malloc_and_write_it
> > * `sleep` for few seconds
> > * numastat > /tmp/after
> > * compares /tmp/before and /tmp/after to check that the numa policy
> > was applied the right way
> >
> > But the problem is that on a host with many NUMA nodes (8) the process
> > of updating that numastats statistics takes some time. Even 10 seconds
> > may be not enough. Therefore the test fails.
> >
> > Is there a direct or indirect way to force the kernel to update the
> > NUMA statistics?
>
> Not currently. It depends on how much memory you have and subsequent
> operations. I guess would need to add one.
The kernel vm statistics are brought up to date with the default
settings every 2 seconds.
The interval is controlled via /proc/sys/vm/stat_interval
Check the value that you have setup there.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-07 15:47 ` Christoph Lameter
@ 2014-04-08 16:49 ` Stanislav Kholmanskikh
-1 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-08 16:49 UTC (permalink / raw)
To: Christoph Lameter, Andi Kleen; +Cc: vasily Isaenko, ltp-list, linux-numa
On 04/07/2014 07:47 PM, Christoph Lameter wrote:
> On Mon, 7 Apr 2014, Andi Kleen wrote:
>
>>> * starts a binary with the specified numa memory policy using
>>> numactl (or a like):
>>> numactl --interleave=all get_some_memory_with_malloc_and_write_it
>>> * `sleep` for few seconds
>>> * numastat > /tmp/after
>>> * compares /tmp/before and /tmp/after to check that the numa policy
>>> was applied the right way
>>>
>>> But the problem is that on a host with many NUMA nodes (8) the process
>>> of updating that numastats statistics takes some time. Even 10 seconds
>>> may be not enough. Therefore the test fails.
>>>
>>> Is there a direct or indirect way to force the kernel to update the
>>> NUMA statistics?
>>
>> Not currently. It depends on how much memory you have and subsequent
>> operations. I guess would need to add one.
>
> The kernel vm statistics are brought up to date with the default
> settings every 2 seconds.
>
> The interval is controlled via /proc/sys/vm/stat_interval
>
> Check the value that you have setup there.
>
Thank you, Andi, Christoph.
In my setup stat_interval is 1.
Please, look at this reproducer:
#!/bin/bash
sum_pages()
{
local i
ret=0
for i in $@; do
ret=$(( $ret + $i ))
done
}
ret=0
for i in `seq 20`; do
sum_pages $( numastat | grep interleav | cut -d ' ' -f 2-)
val_before=$ret
numactl --interleave=all support_numa 2
sleep 2
sum_pages $( numastat | grep interleav | cut -d ' ' -f 2-)
val_after=$ret
echo "$i: $(( $val_after - $val_before))"
done
On a two-node system it prints:
1: 294
2: 294
3: 295
4: 294
5: 294
6: 295
7: 294
8: 294
9: 293
10: 293
11: 294
12: 295
13: 296
14: 293
15: 295
16: 294
17: 295
18: 294
19: 294
20: 294
i.e. everything is ok.
But on an eight-node system:
1: 173
2: 0
3: 0
4: 173
5: 173
6: 0
7: 173
8: 173
9: 0
10: 0
11: 173
12: 0
13: 173
14: 0
15: 346
16: 0
17: 0
18: 89
19: 0
20: 173
So in general we can't rely on stat_interval value. Correct?
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: numastats updates
@ 2014-04-08 16:49 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-08 16:49 UTC (permalink / raw)
To: Christoph Lameter, Andi Kleen; +Cc: linux-numa, ltp-list, vasily Isaenko
On 04/07/2014 07:47 PM, Christoph Lameter wrote:
> On Mon, 7 Apr 2014, Andi Kleen wrote:
>
>>> * starts a binary with the specified numa memory policy using
>>> numactl (or a like):
>>> numactl --interleave=all get_some_memory_with_malloc_and_write_it
>>> * `sleep` for few seconds
>>> * numastat > /tmp/after
>>> * compares /tmp/before and /tmp/after to check that the numa policy
>>> was applied the right way
>>>
>>> But the problem is that on a host with many NUMA nodes (8) the process
>>> of updating that numastats statistics takes some time. Even 10 seconds
>>> may be not enough. Therefore the test fails.
>>>
>>> Is there a direct or indirect way to force the kernel to update the
>>> NUMA statistics?
>>
>> Not currently. It depends on how much memory you have and subsequent
>> operations. I guess would need to add one.
>
> The kernel vm statistics are brought up to date with the default
> settings every 2 seconds.
>
> The interval is controlled via /proc/sys/vm/stat_interval
>
> Check the value that you have setup there.
>
Thank you, Andi, Christoph.
In my setup stat_interval is 1.
Please, look at this reproducer:
#!/bin/bash
sum_pages()
{
local i
ret=0
for i in $@; do
ret=$(( $ret + $i ))
done
}
ret=0
for i in `seq 20`; do
sum_pages $( numastat | grep interleav | cut -d ' ' -f 2-)
val_before=$ret
numactl --interleave=all support_numa 2
sleep 2
sum_pages $( numastat | grep interleav | cut -d ' ' -f 2-)
val_after=$ret
echo "$i: $(( $val_after - $val_before))"
done
On a two-node system it prints:
1: 294
2: 294
3: 295
4: 294
5: 294
6: 295
7: 294
8: 294
9: 293
10: 293
11: 294
12: 295
13: 296
14: 293
15: 295
16: 294
17: 295
18: 294
19: 294
20: 294
i.e. everything is ok.
But on an eight-node system:
1: 173
2: 0
3: 0
4: 173
5: 173
6: 0
7: 173
8: 173
9: 0
10: 0
11: 173
12: 0
13: 173
14: 0
15: 346
16: 0
17: 0
18: 89
19: 0
20: 173
So in general we can't rely on stat_interval value. Correct?
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: numastats updates
2014-04-08 16:49 ` Stanislav Kholmanskikh
@ 2014-04-08 16:57 ` Christoph Lameter
-1 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-08 16:57 UTC (permalink / raw)
To: Stanislav Kholmanskikh
Cc: Andi Kleen, linux-numa, ltp-list, vasily Isaenko,
Frederic Weisbecker, linux-mm
On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> On a two-node system it prints:
> 1: 294
..
> 20: 294
>
> i.e. everything is ok.
>
> But on an eight-node system:
> 1: 173
> 2: 0
> 3: 0
> 4: 173
> 5: 173
> So in general we can't rely on stat_interval value. Correct?
Owww... This could have something to do with the tick being disabled on
idle without regard for pending vmstat updates. The processor goes to
sleep and never updates the global counters. Once in awhile the processor
wakes up to deal with the statistics.
The idle logic needs to check that all differentials are folded before
going to slee. Frederic: Can we add such a check?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
@ 2014-04-08 16:57 ` Christoph Lameter
0 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-08 16:57 UTC (permalink / raw)
To: Stanislav Kholmanskikh
Cc: ltp-list, vasily Isaenko, Frederic Weisbecker, linux-mm,
Andi Kleen, linux-numa
On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> On a two-node system it prints:
> 1: 294
..
> 20: 294
>
> i.e. everything is ok.
>
> But on an eight-node system:
> 1: 173
> 2: 0
> 3: 0
> 4: 173
> 5: 173
> So in general we can't rely on stat_interval value. Correct?
Owww... This could have something to do with the tick being disabled on
idle without regard for pending vmstat updates. The processor goes to
sleep and never updates the global counters. Once in awhile the processor
wakes up to deal with the statistics.
The idle logic needs to check that all differentials are folded before
going to slee. Frederic: Can we add such a check?
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-08 16:49 ` Stanislav Kholmanskikh
@ 2014-04-08 16:58 ` Stanislav Kholmanskikh
-1 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-08 16:58 UTC (permalink / raw)
To: Christoph Lameter, Andi Kleen; +Cc: vasily Isaenko, ltp-list, linux-numa
On 04/08/2014 08:49 PM, Stanislav Kholmanskikh wrote:
>
> On a two-node system it prints:
> 1: 294
> 2: 294
> 3: 295
> 4: 294
> 5: 294
> 6: 295
> 7: 294
> 8: 294
> 9: 293
> 10: 293
> 11: 294
> 12: 295
> 13: 296
> 14: 293
> 15: 295
> 16: 294
> 17: 295
> 18: 294
> 19: 294
> 20: 294
>
> i.e. everything is ok.
>
> But on an eight-node system:
> 1: 173
> 2: 0
> 3: 0
> 4: 173
> 5: 173
> 6: 0
> 7: 173
> 8: 173
> 9: 0
> 10: 0
> 11: 173
> 12: 0
> 13: 173
> 14: 0
> 15: 346
> 16: 0
> 17: 0
> 18: 89
> 19: 0
> 20: 173
>
Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: numastats updates
@ 2014-04-08 16:58 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-08 16:58 UTC (permalink / raw)
To: Christoph Lameter, Andi Kleen; +Cc: linux-numa, ltp-list, vasily Isaenko
On 04/08/2014 08:49 PM, Stanislav Kholmanskikh wrote:
>
> On a two-node system it prints:
> 1: 294
> 2: 294
> 3: 295
> 4: 294
> 5: 294
> 6: 295
> 7: 294
> 8: 294
> 9: 293
> 10: 293
> 11: 294
> 12: 295
> 13: 296
> 14: 293
> 15: 295
> 16: 294
> 17: 295
> 18: 294
> 19: 294
> 20: 294
>
> i.e. everything is ok.
>
> But on an eight-node system:
> 1: 173
> 2: 0
> 3: 0
> 4: 173
> 5: 173
> 6: 0
> 7: 173
> 8: 173
> 9: 0
> 10: 0
> 11: 173
> 12: 0
> 13: 173
> 14: 0
> 15: 346
> 16: 0
> 17: 0
> 18: 89
> 19: 0
> 20: 173
>
Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-08 16:58 ` Stanislav Kholmanskikh
@ 2014-04-08 18:03 ` Christoph Lameter
-1 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-08 18:03 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: vasily Isaenko, ltp-list, Andi Kleen, linux-numa
On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
So they are not x86? There are some counter races on !x86.
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: numastats updates
@ 2014-04-08 18:03 ` Christoph Lameter
0 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-08 18:03 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: Andi Kleen, linux-numa, ltp-list, vasily Isaenko
On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
So they are not x86? There are some counter races on !x86.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-08 18:03 ` Christoph Lameter
@ 2014-04-10 5:44 ` Stanislav Kholmanskikh
-1 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-10 5:44 UTC (permalink / raw)
To: Christoph Lameter; +Cc: vasily Isaenko, ltp-list, Andi Kleen, linux-numa
On 04/08/2014 10:03 PM, Christoph Lameter wrote:
> On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
>
>> Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
>
> So they are not x86? There are some counter races on !x86.
Yes. This is Linux on SPARC.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-numa" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: numastats updates
@ 2014-04-10 5:44 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 20+ messages in thread
From: Stanislav Kholmanskikh @ 2014-04-10 5:44 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andi Kleen, linux-numa, ltp-list, vasily Isaenko
On 04/08/2014 10:03 PM, Christoph Lameter wrote:
> On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
>
>> Forgot to mention. This eight-node system has 8k pages, two-node - 4k pages.
>
> So they are not x86? There are some counter races on !x86.
Yes. This is Linux on SPARC.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-numa" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-10 5:44 ` Stanislav Kholmanskikh
@ 2014-04-11 1:48 ` Christoph Lameter
-1 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-11 1:48 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: vasily Isaenko, ltp-list, Andi Kleen, linux-numa
On Thu, 10 Apr 2014, Stanislav Kholmanskikh wrote:
> On 04/08/2014 10:03 PM, Christoph Lameter wrote:
> > On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> >
> > > Forgot to mention. This eight-node system has 8k pages, two-node - 4k
> > > pages.
> >
> > So they are not x86? There are some counter races on !x86.
>
> Yes. This is Linux on SPARC.
Hmmm... I just got the infrastructure merged to define fast counter
updates. If we would define raw_cpu_ops for sparc then we could fix
the issue. Sparc has atomics that can increment a register relative to a
percpu base register right?
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: numastats updates
@ 2014-04-11 1:48 ` Christoph Lameter
0 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-11 1:48 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: Andi Kleen, linux-numa, ltp-list, vasily Isaenko
On Thu, 10 Apr 2014, Stanislav Kholmanskikh wrote:
> On 04/08/2014 10:03 PM, Christoph Lameter wrote:
> > On Tue, 8 Apr 2014, Stanislav Kholmanskikh wrote:
> >
> > > Forgot to mention. This eight-node system has 8k pages, two-node - 4k
> > > pages.
> >
> > So they are not x86? There are some counter races on !x86.
>
> Yes. This is Linux on SPARC.
Hmmm... I just got the infrastructure merged to define fast counter
updates. If we would define raw_cpu_ops for sparc then we could fix
the issue. Sparc has atomics that can increment a register relative to a
percpu base register right?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [LTP] numastats updates
2014-04-11 1:48 ` Christoph Lameter
@ 2014-04-11 2:12 ` Christoph Lameter
-1 siblings, 0 replies; 20+ messages in thread
From: Christoph Lameter @ 2014-04-11 2:12 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: vasily Isaenko, ltp-list, Andi Kleen, linux-numa
Interrupts are disabled when the hit and miss statistics are
incremented. SO no problem there. Weird situation.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-04-11 2:12 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-03 10:45 [LTP] numastats updates Stanislav Kholmanskikh
2014-04-03 10:45 ` Stanislav Kholmanskikh
2014-04-07 1:39 ` [LTP] " Andi Kleen
2014-04-07 1:39 ` Andi Kleen
2014-04-07 15:47 ` [LTP] " Christoph Lameter
2014-04-07 15:47 ` Christoph Lameter
2014-04-08 16:49 ` [LTP] " Stanislav Kholmanskikh
2014-04-08 16:49 ` Stanislav Kholmanskikh
2014-04-08 16:57 ` Christoph Lameter
2014-04-08 16:57 ` [LTP] " Christoph Lameter
2014-04-08 16:58 ` Stanislav Kholmanskikh
2014-04-08 16:58 ` Stanislav Kholmanskikh
2014-04-08 18:03 ` [LTP] " Christoph Lameter
2014-04-08 18:03 ` Christoph Lameter
2014-04-10 5:44 ` [LTP] " Stanislav Kholmanskikh
2014-04-10 5:44 ` Stanislav Kholmanskikh
2014-04-11 1:48 ` [LTP] " Christoph Lameter
2014-04-11 1:48 ` Christoph Lameter
2014-04-11 2:12 ` [LTP] " Christoph Lameter
2014-04-11 2:12 ` Christoph Lameter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.