On Tue, Jul 30, 2024 at 06:11:06PM +0800, wujing wrote: > > On Tue, Jul 30, 2024 at 05:40:17PM +0800, wujing wrote: > > > > What "current patch"? > > > > > > > > confused, > > > > > > > > greg k-h > > > > > > The current patch is in my first email. > > > > What message exactly? I don't see any such message on the stable list. > > > > > Please ignore the previous two emails. > > > The "current patch" mentioned in the earlier emails refers to the upstream > > > status, but the latest upstream patch can no longer be applied to linux-4.19.y. > > > > Again, please read: > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > for how to do this properly. > > > > thanks, > > > > greg k-h > > The email you just replied to is correct. > > I reviewed the link in the email, and according to the link, > the patch I submitted meets the third criterion. I have noted > Upstream commit <8aeaffef8c6e> in the patch log. > > > > >From 9d4ecc9314088c2b0aa39c2248fb5e64042f1eef Mon Sep 17 00:00:00 2001 > From: wujing <realwujing@xxxxxxxxx> > Date: Tue, 30 Jul 2024 15:35:53 +0800 > Subject: [PATCH] sched/fair: Correct CPU selection from isolated domain > > We encountered an issue where the kernel thread `ksmd` runs on the PMD > dedicated isolated core, leading to high latency in OVS packets. > > Upon analysis, we discovered that this is caused by the current > select_idle_smt() function not taking the sched_domain mask into account. > > Upstream commit <8aeaffef8c6e> > > Kernel version: linux-4.19.y This is not in a format that I can take. Also, this does not match that commit id, so you need to document it really really well why this is different. And you lost the original authorship information, and the reviews. And finally, we can't take a change for 4.19.y that is also not in newer kernel releases, because if we did that, and you upgraded, you would have a regression. But most importantly, why are you still doing stuff on 4.19.y? This kernel is going to go end-of-life very soon, and you should already have all of your systems that rely on it off of it by now, or planned to within a few months. To not do that is to ensure that you will end up with insecure systems when the end-of-life deadline happens. thanks, greg k-h
