All of lore.kernel.org
 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 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.