Re: [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads

2023-01-30 Thread Petr Mladek via Virtualization
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

Re: [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads

2023-01-27 Thread Petr Mladek via Virtualization
On Fri 2023-01-27 11:37:02, Peter Zijlstra wrote: > On Thu, Jan 26, 2023 at 08:43:55PM -0800, Josh Poimboeuf wrote: > > On Thu, Jan 26, 2023 at 03:12:35PM -0600, Seth Forshee (DigitalOcean) wrote: > > > On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote: > > > > On Fri 2023-01-20

Re: [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads

2023-01-27 Thread Petr Mladek via Virtualization
On Thu 2023-01-26 15:12:35, Seth Forshee (DigitalOcean) wrote: > On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote: > > On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote: > > > We've fairly regularaly seen liveptches which cannot transition within > > > kpatch's > > >

Re: [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads

2023-01-26 Thread Petr Mladek via Virtualization
On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote: > We've fairly regularaly seen liveptches which cannot transition within > kpatch's > timeout period due to busy vhost worker kthreads. I have missed this detail. Miroslav told me that we have solved something similar some time ago,

Re: [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads

2023-01-26 Thread Petr Mladek via Virtualization
On Thu 2023-01-26 12:16:36, Petr Mladek wrote: > On Wed 2023-01-25 10:57:30, Seth Forshee wrote: > > On Wed, Jan 25, 2023 at 12:34:26PM +0100, Petr Mladek wrote: > > > On Tue 2023-01-24 11:21:39, Seth Forshee wrote: > > > > On Tue, Jan 24, 2023 at 03:17:43PM +0100, Petr Mladek wrote: > > > > > On

Re: [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads

2023-01-26 Thread Petr Mladek via Virtualization
On Wed 2023-01-25 10:57:30, Seth Forshee wrote: > On Wed, Jan 25, 2023 at 12:34:26PM +0100, Petr Mladek wrote: > > On Tue 2023-01-24 11:21:39, Seth Forshee wrote: > > > On Tue, Jan 24, 2023 at 03:17:43PM +0100, Petr Mladek wrote: > > > > On Fri 2023-01-20 16:12:22, Seth Forshee (DigitalOcean)

Re: [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads

2023-01-25 Thread Petr Mladek via Virtualization
On Tue 2023-01-24 11:21:39, Seth Forshee wrote: > On Tue, Jan 24, 2023 at 03:17:43PM +0100, Petr Mladek wrote: > > On Fri 2023-01-20 16:12:22, Seth Forshee (DigitalOcean) wrote: > > > Livepatch relies on stack checking of sleeping tasks to switch kthreads, > > > so a busy kthread can block a

Re: [PATCH 2/2] vhost: check for pending livepatches from vhost worker kthreads

2023-01-24 Thread Petr Mladek via Virtualization
On Fri 2023-01-20 16:12:22, Seth Forshee (DigitalOcean) wrote: > Livepatch relies on stack checking of sleeping tasks to switch kthreads, > so a busy kthread can block a livepatch transition indefinitely. We've > seen this happen fairly often with busy vhost kthreads. To be precise, it would be

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

2022-06-09 Thread Petr Mladek via Virtualization
On Thu 2022-06-09 12:02:04, Peter Zijlstra wrote: > On Thu, Jun 09, 2022 at 11:16:46AM +0200, Petr Mladek wrote: > > On Wed 2022-06-08 16:27:47, Peter Zijlstra wrote: > > > The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console > > > tracepoint"), was printk usage from the cpuidle path

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

2022-06-09 Thread Petr Mladek via Virtualization
On Thu 2022-06-09 20:30:58, Sergey Senozhatsky wrote: > My emails are getting rejected... Let me try web-interface Bad day for mail sending. I have problems as well ;-) > Kudos to Petr for the questions and thanks to PeterZ for the answers. > > On Thu, Jun 9, 2022 at 7:02 PM Peter Zijlstra

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

2022-06-09 Thread Petr Mladek via Virtualization
Sending again. The previous attempt was rejected by several recipients. It was caused by a mail server changes on my side. I am sorry for spamming those who got the 1st mail already. On Wed 2022-06-08 16:27:47, Peter Zijlstra wrote: > The problem, per commit fc98c3c8c9dc ("printk: use rcuidle

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

2022-06-09 Thread Petr Mladek via Virtualization
On Wed 2022-06-08 16:27:47, Peter Zijlstra wrote: > The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console > tracepoint"), was printk usage from the cpuidle path where RCU was > already disabled. > > Per the patches earlier in this series, this is no longer the case. My understanding

Re: netconsole deadlock with virtnet

2020-11-19 Thread Petr Mladek via Virtualization
On Tue 2020-11-17 09:33:25, Steven Rostedt wrote: > On Tue, 17 Nov 2020 12:23:41 +0200 > Leon Romanovsky wrote: > > > Hi, > > > > Approximately two weeks ago, our regression team started to experience those > > netconsole splats. The tested code is Linus's master (-rc4) + netdev > > net-next >