All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
To: Christoph Lameter <cl@linux.com>, Andi Kleen <andi@firstfloor.org>
Cc: vasily Isaenko <vasily.isaenko@oracle.com>,
	ltp-list <ltp-list@lists.sourceforge.net>,
	linux-numa@vger.kernel.org
Subject: Re: [LTP] numastats updates
Date: Tue, 08 Apr 2014 20:49:18 +0400	[thread overview]
Message-ID: <5344288E.3090306@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1404071044310.9896@nuc>



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

WARNING: multiple messages have this Message-ID (diff)
From: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
To: Christoph Lameter <cl@linux.com>, Andi Kleen <andi@firstfloor.org>
Cc: linux-numa@vger.kernel.org,
	ltp-list <ltp-list@lists.sourceforge.net>,
	vasily Isaenko <vasily.isaenko@oracle.com>
Subject: Re: numastats updates
Date: Tue, 08 Apr 2014 20:49:18 +0400	[thread overview]
Message-ID: <5344288E.3090306@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1404071044310.9896@nuc>



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?

  reply	other threads:[~2014-04-08 16:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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     ` Stanislav Kholmanskikh [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5344288E.3090306@oracle.com \
    --to=stanislav.kholmanskikh@oracle.com \
    --cc=andi@firstfloor.org \
    --cc=cl@linux.com \
    --cc=linux-numa@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=vasily.isaenko@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.