From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5EF3A2248B0 for ; Mon, 8 Dec 2025 11:09:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765192153; cv=none; b=ssZNMiqN9nfm6JZ7AIvMuFtoYDhxcI1dVf2cEpBZ9cpTduyV+4g/DBFSfSJhJfPV9D5oXupzku4PG+XuWC6hCXsq6FQfaD7BTvnNSaV3GYDCdlofo6tZ8I4Y5XNZcaaV9MhrB00tDhGZ/WB6Omvh/3p+QEh0VYyJ3Hea27nTW3w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765192153; c=relaxed/simple; bh=fT4Xv4XY/6ZGpSKbO30wOEFHzhU80jD9nVoy/UD35q4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G2N7JIzYwEa51RHir1qJmktKmOYGgxQiyoW6/b1ErARKcv+mJ+28DDdO3ZWazFBw1XCyWK3zo2RovF+BcHTC1m3x/5KYGvzFaPqAX0aj2v/+MbmQdOxQOBcjBU6luFoZsybNh0C/ZY172GxpBP+IasZaqkwbDwfw0KPpvOL8Fww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=FQnTCcY6; arc=none smtp.client-ip=117.135.210.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="FQnTCcY6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=nb 11IOj5zdtgUfROj0icjI4Qvzfvw7t4QXkryg1Ce/g=; b=FQnTCcY6RbxqeLUJ3A G1smbGtIO+HWX31FCtipxeb4Ui9kR2sqVlCeqalQ/Qo63gDFL12TkAGjkqCwkZ2k FZbKwOoYYBU2YfVQxtjVXye0Les5h2zemjQNXtH/qtQUpN76+p1WnO2WoyG2YsQI WHszQFFDQDGjf+tFHYA6qZzW0= Received: from localhost.localdomain (unknown []) by gzga-smtp-mtada-g1-1 (Coremail) with SMTP id _____wC33fGvsTZpR7QCAg--.27018S4; Mon, 08 Dec 2025 19:08:47 +0800 (CST) From: David Wang <00107082@163.com> To: malcolm@haak.id.au Cc: linux-kernel@vger.kernel.org, surenb@google.com Subject: Re: Possible memory leak in 6.17.7 Date: Mon, 8 Dec 2025 19:08:29 +0800 Message-ID: <20251208110829.11840-1-00107082@163.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20251110182008.71e0858b@xps15mal> References: <20251110182008.71e0858b@xps15mal> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wC33fGvsTZpR7QCAg--.27018S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7ZFy8ArykCr4xuw4xAw17GFg_yoW8Xw43pF 40qr4UGws5twnFg3srXw1DurWfCaykGr43t39xuFn3u3y3WFnFyr18Zr47Z3srJw1UKayF vFsxAr12q3W8ZwUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRF38OUUUUU= X-CM-SenderInfo: qqqrilqqysqiywtou0bp/xtbCxQKEL2k2scLZugAA3j On Mon, 10 Nov 2025 18:20:08 +1000 Mal Haak wrote: > Hello, > > I have found a memory leak in 6.17.7 but I am unsure how to track it > down effectively. > > I am running a server that has a heavy read/write workload to a cephfs > file system. It is a VM. > > Over time it appears that the non-cache useage of kernel dynamic > memory increases. The kernel seems to think the pages are reclaimable > however nothing appears to trigger the reclaim. This leads to > workloads getting killed via oomkiller. > > smem -wp output: > > Area Used Cache Noncache > firmware/hardware 0.00% 0.00% 0.00% > kernel image 0.00% 0.00% 0.00% > kernel dynamic memory 88.21% 36.25% 51.96% > userspace memory 9.49% 0.15% 9.34% > free memory 2.30% 2.30% 0.00% > > free -h output: > > total used free shared buff/cache available > Mem: 31Gi 3.6Gi 500Mi 4.0Mi 11Gi 27Gi > Swap: 4.0Gi 179Mi 3.8Gi > > Reverting to the previous LTS fixes the issue > > smem -wp output: > Area Used Cache Noncache > firmware/hardware 0.00% 0.00% 0.00% > kernel image 0.00% 0.00% 0.00% > kernel dynamic memory 80.22% 79.32% 0.90% > userspace memory 10.48% 0.20% 10.28% > free memory 9.30% 9.30% 0.00% > I think the `memory allocation profiling` feature can help. https://docs.kernel.org/mm/allocation-profiling.html You would need to build a kernel with CONFIG_MEM_ALLOC_PROFILING=y CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y And check /proc/allocinfo for the suspicious allocations which take more memory than expected. (I once caught a nvidia driver memory leak.) FYI David