From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from harvie.cz (harvie.cz [77.87.242.242]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E7C782FF155 for ; Fri, 23 Jan 2026 14:49:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=77.87.242.242 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769179766; cv=none; b=ZqJePsht6qyqYQKIwt1rkcMCxaIWpk4Ytom4dwIjJtq60RS6pJ+bb5i1j879WdMetWncNdniifexeGSoUJF2E3+i6jh+tAnV6zU8ToLRsmRCrWXNkYpXCGcRV0F262xR1CNdar6VQJ6STvCpyRrRAHFccTx3G38PM58AnGWlQwo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769179766; c=relaxed/simple; bh=okvjiXFxIvEJF44yF5M/RTgPG9Iu1WgX3Cu+34b2nMM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hdkkGYSOkq4rt2AfBNFUuN8iOXAf4/aURFKFx4WOMBqoAjmTyAtN7chQwb5AbzFaKo/A4QJ/us2XnyvCH7Eu0JiBBeoS3BjPnRwTf3qa7CZnDENkNHeM+MOX5seLyhPg2VghvEV9Mq08OJhip3jX8b46H9zuyYg1CLHapJU6UU8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com; spf=fail smtp.mailfrom=gmail.com; arc=none smtp.client-ip=77.87.242.242 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=gmail.com Received: from anemophobia.amit.cz (unknown [31.30.84.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by harvie.cz (Postfix) with ESMTPSA id 5A551180102; Fri, 23 Jan 2026 15:49:21 +0100 (CET) From: Tomas Mudrunka To: tomas.mudrunka@gmail.com Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rppt@kernel.org Subject: CPU Cache in Linux MemTest Date: Fri, 23 Jan 2026 15:49:08 +0100 Message-ID: <20260123144908.65146-1-tomas.mudrunka@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260122150116.3409572-1-tomas.mudrunka@gmail.com> References: <20260122150116.3409572-1-tomas.mudrunka@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Also it seems that CPU cache is not disabled during early_memtest() and there is no easy way to disable it globally at this stage of boot. However it can be invalidated using macros like clflush() and mb(). Unfortunately those are very x86 architecture-specific. This probably means we can use ifdefs to call the correct cache flush macro for given architecture and disable the test altogether for unsupported architectures. Alternatively it might be possible to do large write somewhere else to flush the cache. After all current memtest seems to heavily rely solely on the fact the test pattern is written in large regions at time. It might be possible to do opportunistic cache flush based on the same ifdef logic when flush instruction is available on given architecture for use in existing memtest code. Hopefully even implementing some simple abstraction layer for this. Can you please give me some feedback on this approach? Thanks Tom