Message-id: <53ADCD3B.3000209@samsung.com>
Date: Fri, 27 Jun 2014 13:59:55 -0600
From: Shuah Khan <shuah.kh@samsung.com>
Reply-to: shuah.kh@samsung.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
 Thunderbird/24.6.0
MIME-version: 1.0
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
References: <1403814836-16964-1-git-send-email-shuah.kh@samsung.com>
 <20140626145106.83d8a15bfa07270b00e5d24b@linux-foundation.org>
 <53ADA58D.4070307@samsung.com>
 <20140627124552.d834ecd58c416c0a2d0dae02@linux-foundation.org>
In-reply-to: <20140627124552.d834ecd58c416c0a2d0dae02@linux-foundation.org>
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/