mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yongqiang Liu <liuyongqiang13@huawei.com>
To: <vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>,
	<xuyang2018.jy@fujitsu.com>, <liwang@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<vincent.guittot@linaro.org>, <mingo@redhat.com>,
	<peterz@infradead.org>, <mgorman@suse.de>,
	<akpm@linux-foundation.org>, <vbabka@suse.cz>,
	"David Hildenbrand" <david@redhat.com>, <willy@infradead.org>,
	"Wangkefeng (OS Kernel Lab)" <wangkefeng.wang@huawei.com>
Subject: [QUESTION] ltp: mavise06 failed when the task scheduled to another cpu
Date: Mon, 11 Oct 2021 16:14:16 +0800	[thread overview]
Message-ID: <5ed4bc3d-9c30-8cae-e826-b2d0c37c2f6e@huawei.com> (raw)

Hi,

when runing this case in 5.10-lts kernel, it will trigger the folloing 
failure:

  ......

     madvise06.c:74: TINFO:  memory.kmem.usage_in_bytes: 1752 Kb
     madvise06.c:208: TPASS: more than 102400 Kb were moved to the swap 
cache
     madvise06.c:217: TINFO: PageFault(madvice / no mem access): 102401
     madvise06.c:221: TINFO: PageFault(madvice / mem access): 102417
     madvise06.c:82: TINFO: After page access
     madvise06.c:84: TINFO:  Swap: 307372 Kb
     madvise06.c:86: TINFO:  SwapCached: 101820 Kb
     madvise06.c:88: TINFO:  Cached: 103004Kb
     madvise06.c:74: TINFO:  memory.kmem.usage_in_bytes: 0Kb
     madvise06.c:225: TFAIL: 16 pages were faulted out of 2 max

and we found that when we call the madvise the task was scheduled to 
another cpu:

......

tst_res(TINFO, "before madvise MEMLIMIT CPU:%d", sched_getcpu());--->cpu0

TEST(madvise(target, MEM_LIMIT, MADV_WILLNEED));

tst_res(TINFO, "after madvise MEMLIMIT CPU:%d", sched_getcpu());--->cpu1

......

tst_res(TINFO, "before madvise PASS_THRESHOLDCPU:%d", 
sched_getcpu());-->cpu1

TEST(madvise(target, PASS_THRESHOLD, MADV_WILLNEED));

tst_res(TINFO, "after madvise PASS_THRESHOLDCPU:%d", 
sched_getcpu());-->cpu0

.....

Is the PERCPU data swap_slot was not handled well?


with the following patch almost fix the error:

e9b9734b7465 sched/fair: Reduce cases for active balance

8a41dfcda7a3 sched/fair: Don't set LBF_ALL_PINNED unnecessarily

fc488ffd4297 sched/fair: Skip idle cfs_rq

but bind the task to a cpu also can solve this problem.

Kind regards,


             reply	other threads:[~2021-10-11  8:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11  8:14 Yongqiang Liu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-09-29 12:38 Yongqiang Liu

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=5ed4bc3d-9c30-8cae-e826-b2d0c37c2f6e@huawei.com \
    --to=liuyongqiang13@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwang@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vbabka@suse.cz \
    --cc=vincent.guittot@linaro.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=xuyang2018.jy@fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®