On Fri, 27 Jun 2014 11:10:37 -0600 Shuah Khan <[email protected]> wrote:
> On 06/26/2014 03:51 PM, Andrew Morton wrote: > > On Thu, 26 Jun 2014 14:33:56 -0600 Shuah Khan <[email protected]> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
