public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC] [PATCH] move_pages12: Allocate and free hugepages prior	the test
Date: Wed, 10 May 2017 14:21:40 +0200	[thread overview]
Message-ID: <20170510122130.GD29838@rei.suse.de> (raw)
In-Reply-To: <510505896.9544779.1494406598104.JavaMail.zimbra@redhat.com>

Hi!
> I'm still getting sporadic failures with 4.11 kernel. It's freshly
> booted system, so I would expect fragmentation to be low:
> 
> # numactl -H; ./move_pages12 
> available: 2 nodes (0-1)
> node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
> node 0 size: 31963 MB
> node 0 free: 31600 MB
> node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
> node 1 size: 32251 MB
> node 1 free: 31915 MB
> node distances:
> node   0   1 
>   0:  10  20 
>   1:  20  10
> 
> tst_test.c:847: INFO: Timeout per run is 0h 05m 00s
> move_pages12.c:184: INFO: Free RAM 65040204 kB
> move_pages12.c:139: INFO: Allocating and freeing 2 hugepages on node 0
> move_pages12.c:139: INFO: Allocating and freeing 2 hugepages on node 1
> nodes: 0 1
> move_pages12.c:87: FAIL: move_pages failed: ENOMEM

Hmm, reproduced here as well. One of the 100 runs failed for me as well.

I've looked at the code in mm/migrate.c but so far I could not spot a
place where it could fail with ENOMEM (apart from very unlikely single
page allocation which is used to store the parameters passed to the
syscall).

If I comment out the memset() in the test main loop the failure does not
seem to happen. So my guess is that the failure happens when we try to
isolate a page that is in the process of teardown and we get the ENOMEM
somewhere from the memory management internals and that it's OK to
ignore this failure. But that is just a wild guess.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2017-05-10 12:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-09 14:04 [LTP] [RFC] [PATCH] move_pages12: Allocate and free hugepages prior the test Cyril Hrubis
2017-05-10  8:56 ` Jan Stancek
2017-05-10 12:21   ` Cyril Hrubis [this message]
2017-05-10 13:01     ` Jan Stancek
2017-05-10 13:49   ` Cyril Hrubis
2017-05-10 14:14     ` Jan Stancek
2017-05-10 15:08       ` Cyril Hrubis
2017-05-11  6:40         ` Jan Stancek
2017-05-11 12:26           ` Cyril Hrubis
2017-05-11 12:50             ` Jan Stancek
2017-05-16  9:30               ` Cyril Hrubis

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=20170510122130.GD29838@rei.suse.de \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox