All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <shuah.kh@samsung.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: gregkh@linuxfoundation.org, keescook@chromium.org,
	michael@ellerman.id.au, fweisbec@gmail.com,
	benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
	Shuah Khan <shuah.kh@samsung.com>
Subject: Re: [PATCH] tools: selftests - create a separate hotplug target
Date: Fri, 27 Jun 2014 13:59:55 -0600	[thread overview]
Message-ID: <53ADCD3B.3000209@samsung.com> (raw)
In-Reply-To: <20140627124552.d834ecd58c416c0a2d0dae02@linux-foundation.org>

On 06/27/2014 01:45 PM, Andrew Morton wrote:
> On Fri, 27 Jun 2014 11:10:37 -0600 Shuah Khan <shuah.kh@samsung.com> wrote:
>
>> On 06/26/2014 03:51 PM, Andrew Morton wrote:
>>> On Thu, 26 Jun 2014 14:33:56 -0600 Shuah Khan <shuah.kh@samsung.com> wrote:
>>>
>>>> On some systems, hotplug tests could hang forever waiting for cpu and
>>>> memory to be ready to be offlined. A special hotplug target is created,
>>>> which will help run non-hotplug tests and run hotplug tests as a special
>>>> case. Individual hotplug tests can still be run as a special target
>>>> targeted for a single subsystem.
>>>
>>> This is a bit sad.  The general philosophy with selftests is that they
>>> should run to completion even if the kernel/hardware which they are
>>> testing isn't available - they should work it out for themselves.
>>>
>>> But that's obviously a problem with hotplug.  And with networking or
>>> anything else which needs external action.
>>>
>>> On the other hand, networking has loopback and the kernel supports cpu
>>> hotplug simulation via procfs.  So perhaps the cpu and memory hotplug
>>> tests should be redone so they do the plug/unplug injection themselves,
>>> so they can run without external intervention?
>>
>> Changing/running the tests in a safe mode (least possibility of hang)
>> mode is another option. This way the tests are run in normal mode with
>> reduced scope. Memory hotplug test has the ratio option and when I
>> specified low ratio 1-5%, it completed in a few seconds.
>>
>> cpu-hotplug test will require changes. I am working on a change to
>> offline a user specified # of cpus instead offlining all hotpluggable
>> cpus and then onlining them again at the end of the test.
>>
>> When all selftests are run, safe mode hotplug tests will be run.
>>
>> Does this approach sound reasonable?
>
> I don't know really.  You know more about this than I - what advantages
> does the separate-make-target approach have over this approach?
>

Currently these tests run with full range - i.e try to offline
all cpus that are hotpluggable and try to offline all memory
that is hotpluggable. This results in hangs.

Creating a separate target the way I did it in this patch excludes these
tests all together. i.e when somebody runs:

make -C tools/testing/selftests run_tests

hotplug tests don't run.

Instead, with a few changes, tests can be run with a reduced scope so
a % of the memory gets offlined as opposed to all of it and the same
thing with cpus. This way hotplug code gets tested as opposed to
being excluded in a default test run case.

However, if limited scope testing isn't useful, separate target is
better until tests can be made safe to run without hangs.

-- Shuah

-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

  reply	other threads:[~2014-06-27 20:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 20:33 [PATCH] tools: selftests - create a separate hotplug target Shuah Khan
2014-06-26 21:51 ` Andrew Morton
2014-06-27 17:10   ` Shuah Khan
2014-06-27 19:45     ` Andrew Morton
2014-06-27 19:59       ` Shuah Khan [this message]
2014-06-27 20:04         ` Andrew Morton

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=53ADCD3B.3000209@samsung.com \
    --to=shuah.kh@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    /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.