Re: [PATCH v10 05/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

[Chris Metcalf <cmetcalf@mellanox.com>]

On 03/03/2016 01:34 PM, Andi Kleen wrote:
> Chris Metcalf <cmetcalf@ezchip.com> writes:
>>   
>> +config TASK_ISOLATION_ALL
>> +	bool "Provide task isolation on all CPUs by default (except CPU 0)"
>> +	depends on TASK_ISOLATION
>> +	help
>> +	 If the user doesn't pass the task_isolation boot option to
>> +	 define the range of task isolation CPUs, consider that all
>> +	 CPUs in the system are task isolation by default.
>> +	 Note the boot CPU will still be kept outside the range to
>> +	 handle timekeeping duty, etc.
> That seems like a very dangerous Kconfig option.
> "CONFIG_BREAK_EVERYTHING"
> If someone sets that by default they will have a lot of trouble.
>
> I wouldn't add that, make it a run time option only.

So you were thinking, allow a special boot syntax "task_isolation=all",
which puts all the cores into task isolation mode except the boot core?

My original argument was that it was so parallel to the existing
CONFIG_NO_HZ_FULL_ALL option that it just made sense to do it,
and some testers complained about having to specify the precise
cpu range, so this seemed like an easy fix.

The commit comment for NO_HZ_FULL_ALL (f98823ac758ba) reads:

     nohz: New option to default all CPUs in full dynticks range
    
     Provide a new kernel config that defaults all CPUs to be part
     of the full dynticks range, except the boot one for timekeeping.
    
     This default setting is overriden by the nohz_full= boot option
     if passed by the user.
    
     This is helpful for those who don't need a finegrained range
     of full dynticks CPU and also for automated testing.

The same arguments would seem to apply to TASK_ISOLATION_ALL;
note that applications don't actually go into task isolation mode
without issuing the appropriate prctl(), so it shouldn't be too
dangerous if users enable it by mistake.  There will be some
extra checks at kernel entry and exit, that's all.

So on balance it still seems like a reasonable choice.  Thoughts?

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com