[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250625132545.1772c6ab@kernel.org>
Date: Wed, 25 Jun 2025 13:25:45 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jaroslav Pulchart <jaroslav.pulchart@...ddata.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@...el.com>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"Keller, Jacob E" <jacob.e.keller@...el.com>, "Damato, Joe"
<jdamato@...tly.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, Michal Swiatkowski
<michal.swiatkowski@...ux.intel.com>, "Czapnik, Lukasz"
<lukasz.czapnik@...el.com>, "Dumazet, Eric" <edumazet@...gle.com>, "Zaki,
Ahmed" <ahmed.zaki@...el.com>, Martin Karsten <mkarsten@...terloo.ca>, Igor
Raits <igor@...ddata.com>, Daniel Secik <daniel.secik@...ddata.com>, Zdenek
Pesek <zdenek.pesek@...ddata.com>
Subject: Re: [Intel-wired-lan] Increased memory usage on NUMA nodes with ICE
driver after upgrade to 6.13.y (regression in commit 492a044508ad)
On Wed, 25 Jun 2025 19:51:08 +0200 Jaroslav Pulchart wrote:
> Great, please send me a link to the related patch set. I can apply them in
> our kernel build and try them ASAP!
Sorry if I'm repeating the question - have you tried
CONFIG_MEM_ALLOC_PROFILING? Reportedly the overhead in recent kernels
is low enough to use it for production workloads.
> st 25. 6. 2025 v 16:03 odesÃlatel Przemek Kitszel <
> przemyslaw.kitszel@...el.com> napsal:
>
> > On 6/25/25 14:17, Jaroslav Pulchart wrote:
> > > Hello
> > >
> > > We are still facing the memory issue with Intel 810 NICs (even on latest
> > > 6.15.y).
> > >
> > > Our current stabilization and solution is to move everything to a new
> > > INTEL-FREE server and get rid of last Intel sights there (after Intel's
> > > CPU vulnerabilities fuckups NICs are next step).
> > >
> > > Any help welcomed,
> > > Jaroslav P.
> > >
> > >
> >
> > Thank you for urging us, I can understand the frustration.
> >
> > We have identified some (unrelated) memory leaks, will soon ship fixes.
> > And, as there were no clear issue with any commit/version you have
> > posted to be a culprit, there is a chance that our random findings could
> > help. Anyway going to zero kmemleak reports is good in itself, that is
> > a good start.
> >
> > Will ask my VAL too to increase efforts in this area too.
Powered by blists - more mailing lists