On 01.02.24 18:19, Jaroslav Pulchart wrote: >> >> On Wed, 24 Jan 2024 15:29:38 +0100 Linux regression tracking (Thorsten >> Leemhuis) wrote: >>>>> I think that's a bad bisect. There is no reason I could understand for >>>>> that change to cause a continuous or large leak, it really doesn't make >>>>> any sense. Reverting it consistently helps? You're not just rewinding >>>>> the tree back to that point, right? just running 6.6.9 without that >>>>> patch? (sorry for being pedantic, just trying to be certain) >>>> >>>> Reverting just the single bisected commit continuously helps for >= >>>> 6.6.9 and as well for current 6.7. >>>> We cannot use any new linux kernel without reverting it due to this >>>> extra memory utilization. >>> >>> Quick query: what's the status wrt to this regression? Looks like >>> nothing happened in the past week. >> >> Is someone working on this? Indeed the commit in question looks >> harmless but can't argue with the revert helping :S > > No clue if someone is working on it,
Yeah, a quick public status update would be really helpful. And maybe some debugging tips that might enable Jaroslav to pinpoint the real problem. > however the commit itself is a > trigger of some other issue. > > The analysis of my colleague Igor (see previous email) shows the > memory consumption is caused by queues of each ice network interface > (even the unused ones). Our final fix was to lower the queues to 6 for > used interfaces and 2 of unused interfaces manually. Despite the above allow me to ask: Can you live with that workaround? Ideally of course this should be fixed, but well, the world sometimes is a tricky place. :-/ Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke
