Re: Unexpected switches to in-band

["Łukasz Majewski" <lukma@nabladev.com>]

Hi Philippe,

> 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.
> 

IMHO, it would be enough if we would have:

1. evl check complaining loudly about CONFIG_COMPACTION=y and
CONFIG_MIGRATION=y

2. Just adjust Kconfig to have:
CONFIG_MIGRATION if !DOVETAIL



-- 
Best regards,

Lukasz Majewski

--
Nabla Software Engineering GmbH
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@nabladev.com
Geschftsfhrer : Stefano Babic