public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Xiao Yang <yangx.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3] memcg_stress_test.sh: ported to newlib
Date: Thu, 14 Feb 2019 16:32:52 +0800	[thread overview]
Message-ID: <5C6527B4.4060204@cn.fujitsu.com> (raw)
In-Reply-To: <20190204233435.GA14637@dell5510>

On 2019/02/05 7:34, Petr Vorel wrote:
> Hi Cristian,
>
>> Tested from you branch with ToT as:
>> 10df48aa7 (HEAD ->  pevik_ltp/christian/memcg_stress_test.sh.v3.fixes)
>> memcg_stress_test.sh: fix memory usage
>> ebd6efaa6 memcg_stress_test.sh: Further cleanup
>> 02c520928 memcg_stress_test.sh: ported to newlib
>> fc544f842 controllers/mem_process.c: Fix comparison warning
>> ...
>> on 4k/64k pages defocnfig....looks fine to me.
>> Thanks a lot for the cleanup.
> Thanks a lot for testing!
> Pushed (with your Tested-by on my commit).
>
> I did few cleanup changes in my commit (TINFO messages, fix missing local pid, redirect
> stderr for wait to make it quiet, move TPASS message into run_stress()).
>
> I wonder how to suppress kill message for the first cgroup pid:
> /opt/ltp/testcases/bin/memcg_stress_test.sh: line 65: 14750 User defined signal 1   memcg_process_stress $mem_size $interval

Hi Petr, Cristian

I also saw the same message occasionally when running memcg_stress_test, 
as below:
-----------------------------------------------------------------------
...
/opt/ltp/testcases/bin/memcg_stress_test.sh: line 65: 11262 User defined 
signal 1   memcg_process_stress $mem_size $interval
/opt/ltp/testcases/bin/memcg_stress_test.sh: line 65: 11264 User defined 
signal 1   memcg_process_stress $mem_size $interval
/opt/ltp/testcases/bin/memcg_stress_test.sh: line 65: 11267 User defined 
signal 1   memcg_process_stress $mem_size $interval
...
-----------------------------------------------------------------------

It is possible for memcg_process_stress to be killed by SIGUSR1(default 
action), because it may
have received SIGUSR1 before completing the specified initialization of 
SIGUSR1 signal action.

Perpahs, we should sleep a few seconds to wait for the completion of 
initializing SIGUSR1 signal action. :-)

Please see my patch for details:
-----------------------------------------------------------------------
diff --git 
a/testcases/kernel/controllers/memcg/stress/memcg_stress_test.sh 
b/testcases/kernel/controllers/memcg/stress/memcg_stress_test.sh
index 5b19cc2..697a973 100755
--- a/testcases/kernel/controllers/memcg/stress/memcg_stress_test.sh
+++ b/testcases/kernel/controllers/memcg/stress/memcg_stress_test.sh
@@ -81,6 +81,13 @@ run_stress()
                 pids="$! $pids"
         done

+       # If memcg_process_stress has received SIGUSR1 before completing the
+       # specified initialization of SIGUSR1 signal action, 
memcg_process_stress
+       # will be killed by SIGUSR1(i.e. default action).  So we should 
wait for
+       # the completion of initializing SIGUSR1 signal action by 
sleeping a few
+       # seconds.
+       sleep 2
+
         for pid in $pids; do
                 kill -USR1 $pid 2> /dev/null
         done
-----------------------------------------------------------------------

Best Regards,
Xiao Yang

> This pid is the only one killed by -USR1, but line 65 is not in fist kill loop.
> Therefore it cannot be killed by -KILL (second kill loop).
>
> Kind regards,
> Petr
>
>




  parent reply	other threads:[~2019-02-14  8:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-04 10:54 [LTP] [PATCH v3 0/1] memcg_stress newlib porting Cristian Marussi
2019-01-04 10:54 ` [LTP] [PATCH v3] memcg_stress_test.sh: ported to newlib Cristian Marussi
2019-01-28 16:32   ` Petr Vorel
2019-01-29 17:50     ` Petr Vorel
2019-01-29 19:25       ` Cristian Marussi
2019-02-01 13:45         ` Petr Vorel
2019-02-04 11:56           ` Cristian Marussi
2019-02-04 23:34             ` Petr Vorel
2019-02-05 17:46               ` Cristian Marussi
2019-02-14  8:32               ` Xiao Yang [this message]
2019-02-15 10:09                 ` Cristian Marussi

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=5C6527B4.4060204@cn.fujitsu.com \
    --to=yangx.jy@cn.fujitsu.com \
    --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