Re: Unexpected switches to in-band

[Philippe Gerum <rpm@xenomai.org>]

Giulio Moro <giulio@bela.io> writes:

> Hi everyone,
>
>> CONFIG_COMPACTION=n - it also automatically set CONFIG_MIGRATION=n
>>  From the Kconfig dependencies CONFIG_MIGRATION=n -> !PREEMPT_RT
>> [=n]
>> (i.e. it can be only enabled when PREEMPT_RT is NOT)
>> I've just set CONFIG_COMPACTION=n (which also disabled the
>> CONFIG_MIGRATION) and now I cannot reproduce the issue on my setup (i.e.
>> v6.6.) anymore.
>> It looks like those (enabled by default) config options have slipped
>> in
>> silently and introduced the issue...
>> 
>
> I can confirm disabling CONFIG_COMPACTION and CONFIG_MIGRATION fixed the issue for me as well. Fun fact is that I started looking over these options when I first raised the issue, but then realised that evl check did not flag them as problematic, giving me a false sense of security ...
> Without knowing much about the internals, in hindsight it makes perfect sense that the process was more likely to fail early on in the lifteime of the process and/or of the kernel than after it had been running for a long time: once the memory layout has settled, it's unlikely it will get moved again.
>
> By the way, I was thinking that replacing an in-menuconfig warning (a
> la Xenomai-3) would be nice to have, instead of having to manually run
> evl check on the config file.

Actually, we want both. Some automated configuration process may not
give us any hint loud enough, a runtime check is always welcome,
especially when providing support.

-- 
Philippe.