On Fri 2023-01-27 08:57:40, Seth Forshee wrote: > On Fri, Jan 27, 2023 at 12:19:03PM +0100, Petr Mladek wrote: > > Could you please provide some more details about the test system? > > Is there anything important to make it reproducible? > > > > The following aspects come to my mind. It might require: > > > > + more workers running on the same system > > + have a dedicated CPU for the worker > > + livepatching the function called by work->fn() > > + running the same work again and again > > + huge and overloaded system > > I'm isolating a CPU, starting a KVM guest with a virtio-net device, and > setting the affinity of the vhost worker thread to only the isolated > CPU. Thus the vhost-worker thread has a dedicated CPU, as you say. (I'll > note that in real-world cases the systems have many CPUs, and while the > vhost threads aren't each given a dedicated CPU, if the system load is > light enough a thread can end up with exlusive use of a CPU). > > Then all I do is run iperf between the guest and the host with several > parallel streams. I seem to be hitting the limits of the guest vCPUs > before the vhost thread is fully saturated, as this gets it to about 90% > CPU utilization by the vhost thread. Thanks for the info! > > > > Honestly, kpatch's timeout 1 minute looks incredible low to me. Note > > > > that the transition is tried only once per minute. It means that there > > > > are "only" 60 attempts. > > > > > > > > Just by chance, does it help you to increase the timeout, please? > > > > > > To be honest my test setup reproduces the problem well enough to make > > > KLP wait significant time due to vhost threads, but it seldom causes it > > > to hit kpatch's timeout. > > > > > > Our system management software will try to load a patch tens of times in > > > a day, and we've seen real-world cases where patches couldn't load > > > within kpatch's timeout for multiple days. But I don't have such an > > > environment readily accessible for my own testing. I can try to refine > > > my test case and see if I can get it to that point. > > > > My understanding is that you try to load the patch repeatedly but > > it always fails after the 1 minute timeout. It means that it always > > starts from the beginning (no livepatched process). > > > > Is there any chance to try it with a longer timeout, for example, one > > hour? It should increase the chance if there are more problematic kthreads. > > Yes, I can try it. But I think I already mentioned that we are somewhat > limited by our system management software and how livepatch loading is > currently implemented there. I'd need to consult with others about how > long we could make the timeout, but 1 hour is definitely too long under > our current system. Another possibility is to do not wait at all. SUSE livepatch packages load the livepatch module, remove not longer used livepatch modules and are done with it. Note that the module is loaded quickly. The transition is finished asynchronously using workqueues. Of course, there is a risk that the transition will never finish. It would prevent loading any newer livepatch. But it might be handled when the the newer livepatch is loaded. It might revert the pending transition, ... Of course, it would be great to make the transition more reliable. It would be nice to add the hook into the scheduler as discussed in another branch of this thread. But it might bring another problems, for example, affect the system performance. Well, it probably can be optimized or ratelimited. Anyway, I wanted to say that there is a way to get rid of the timeout completely. Best Regards, Petr
