On Wed, Nov 13, 2019 at 1:02 PM Dick Hollenbeck <dick@xxxxxxxxxxx> wrote: > > On 11/12/19 2:33 PM, Paul Thomas wrote: > > I hope this helps. Good luck! > > > > -Paul > > > [PATCH] needed > > Hi Paul, > > A+ for your help. Thanks very much for your valuable time and excellent post. > > The problem is two fold: > > 1) the configuration variable CONFIG_HOTPLUG_CPU controls the existence of the > *definition* of 'takedown_cpu_task' at kernel/cpu.c line 880. (The *declaration* is in a > header file.) But there's a usage at kernel/sched/core.c line 7399 and following line > which is not conditioned on that same CONFIG_HOTPLUG_CPU config variable. > > 3) The linker message is misleading. All they had to say was that the symbol was > undefined. The continued detail about this being an offset out of range issue created > ambiguity as to whether this was out of range first and foremost, leading to the undefined > status. Clearly now it is simply an undefined usage. > > I am looking for a low latency transfer of control from a GPIO interrupt handler that I > wrote in one of my drivers, all the way to a high RT priority wait_queue blocked user > thread. And stock (non-RT) 5.1 kernel was atrocious, simply unbelievably bad. Somewhere > along the way during the great hunt for improvement I turned off CONFIG_HOTPLUG_CPU just > to try a simpler config. > > > BTW cyclictest on that same stock 5.1 kernel was showing an intermittent 4 msecs of delay. > Yes msecs, not usecs. > > > I would have submitted a patch for this but since its so trivial, it seems somebody with > commit rights could make this change faster than applying a patch. Yup, with CONFIG_HOTPLUG_CPU not set I get the same compile failure. It looks like those two references to takedown_cpu_task should be conditional on CONFIG_HOTPLUG_CPU like you said, but I'll leave that to others to look at. -Paul
