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

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) wrote: > > > > > Livepatch relies on stack checking of

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 16:12:20, Seth Forshee (DigitalOcean) wrote: > > > > We've fairly regularaly seen liveptches which cannot transition within

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 > > > timeout period due to busy vhost worker kthreads. > > > > I have

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, see https://lore.kernel.org/all/20220507174628.2086373-1-song at kernel.org/ Honestly,

Hi, I am running CentOS Linux release 7.7.1908 (Core). Does CentOS Linux kernel 3.10.0-1062.1.1.el7.x86_64 support kernel updates without rebooting (Live Patching)? I look forward to hearing from you and thanks in advance. Best Regards, Kaushal

On Wed, Oct 9, 2019 at 11:27 AM Kaushal Shriyan <kaushalshriyan at gmail.com> wrote: > Hi, > > I am running CentOS Linux release 7.7.1908 (Core). Does CentOS Linux kernel > 3.10.0-1062.1.1.el7.x86_64 support kernel updates without rebooting (Live > Patching)? > > I look forward to hearing from you and thanks in advance. > > > this was just discussed in length

Seth Forshee noticed a performance degradation with some workloads. This turns out to be due to packet drops. Euan Kemp noticed that this is because we drop all packets where length exceeds the truesize, but for some packets we add in extra memory without updating the truesize. This in turn was kept around unchanged from ab7db91705e95 ("virtio-net: auto-tune mergeable rx buffer size for

Seth Forshee noticed a performance degradation with some workloads. This turns out to be due to packet drops. Euan Kemp noticed that this is because we drop all packets where length exceeds the truesize, but for some packets we add in extra memory without updating the truesize. This in turn was kept around unchanged from ab7db91705e95 ("virtio-net: auto-tune mergeable rx buffer size for

Hello, By having a look at 'drivers/platform/x86/apple-gmux.c', it seems its author is Seth Forshee <seth.forshee at canonical.com>. Other main contributors are Andreas Heider <andreas at meetr.de>, and Matthew Garrett <mjg at redhat.com>, among others. Pierre Moreau On 11:58 PM - Jul 26 2014, Evan Foss wrote: > Hello, > > Sorry I know this might be the

On Thu, Jul 27, 2017 at 04:14:30PM -0500, Seth Forshee wrote: > On Thu, Jul 27, 2017 at 11:38:52PM +0300, Michael S. Tsirkin wrote: > > On Thu, Jul 27, 2017 at 12:09:42PM -0500, Seth Forshee wrote: > > > I'm seeing a performance regression with virtio_net that looks to have > > > started in 4.12-rc1. I only see it in one context though, downloading > > >

On Thu, Jul 27, 2017 at 04:14:30PM -0500, Seth Forshee wrote: > On Thu, Jul 27, 2017 at 11:38:52PM +0300, Michael S. Tsirkin wrote: > > On Thu, Jul 27, 2017 at 12:09:42PM -0500, Seth Forshee wrote: > > > I'm seeing a performance regression with virtio_net that looks to have > > > started in 4.12-rc1. I only see it in one context though, downloading > > >

On Thu, Jul 27, 2017 at 12:09:42PM -0500, Seth Forshee wrote: > I'm seeing a performance regression with virtio_net that looks to have > started in 4.12-rc1. I only see it in one context though, downloading > snap packages from the Ubuntu snap store. For example: > > https://api.snapcraft.io/api/v1/snaps/download/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap > > which

On Thu, Jul 27, 2017 at 12:09:42PM -0500, Seth Forshee wrote: > I'm seeing a performance regression with virtio_net that looks to have > started in 4.12-rc1. I only see it in one context though, downloading > snap packages from the Ubuntu snap store. For example: > > https://api.snapcraft.io/api/v1/snaps/download/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap > > which

Hi guys! I'm getting the following warn on 4.15-rc1, on GTX 560 Ti: [ 9.430433] nouveau 0000:01:00.0: NVIDIA GF114 (0ce000a1) ... [ 9.585172] nouveau 0000:01:00.0: bios: version 70.24.2e.00.02 ... [ 9.772204] nouveau 0000:01:00.0: fb: 1024 MiB GDDR5 [ 9.777342] ------------[ cut here ]------------ [ 9.782106] refcount_t: increment on 0; use-after-free. [ 9.787522] WARNING:

Instead of storing the map per CPU provide and use per task storage. That prepares for local kmaps which are preemptible. The context switch code is preparatory and not yet in use because kmap_atomic() runs with preemption disabled. Will be made usable in the next step. The context switch logic is safe even when an interrupt happens after clearing or before restoring the kmaps. The kmap index in

This series implements NAPI + kthread 1:1 model for Xen netback. This model - provides better scheduling fairness among vifs - is prerequisite for implementing multiqueue for Xen network driver The first two patches are ground work for the third patch. They aim to reduce memory footprint of netback. The third patch has the real meat: - make use of NAPI to mitigate interrupt - kthreads are

Hi,all I am newer to Asterisk.My Asterisk version is the newest CVS-HEAD.now something appears in the console CLI like below these,I don't know what's happen to my Asterisk Server.Could anybody help me? Thanks Junk at the beginning Warning, flexibel rate not heavily tested! Junk at the beginning Warning, flexibel rate not heavily tested! Warning, flexibel rate not heavily tested!

Hello, I have several heavily modified RH9 machines (custom kernels, reiser FS, etc.) Just wondering if CentOS could do an upgrade install on machines such as this? I know it's always better to do a clean install, but these machines have been tweaked a lot over the last year and are running perfectly (a lot of time and effort went into this)... an upgrade install would be great. My main

On 11 Jul 2018, at 8.41, Wolfgang Rosenauer <wrosenauer at gmail.com> wrote: > > Hi, > > I'm running 2.2.36 (as provided by openSUSE in their server:mail repository) and at least at one of my systems LMTP is crashing regularly on certain messages (apparently a lot of them). > > Sometimes (but not always a backtrace is posted to the logs: > >

follow up question. Is there a commit which is reasonable to backport for me into the packages or is it too intrusive or based on heavily changed code? Thanks, Wolfgang On Wed, Jul 11, 2018 at 3:32 PM, Wolfgang Rosenauer <wrosenauer at gmail.com> wrote: > > On Wed, Jul 11, 2018 at 10:46 AM, Timo Sirainen <tss at iki.fi> wrote: > >> On 11 Jul 2018, at 8.41, Wolfgang