On Tue, 18 Dec 2007 17:06:24 +0000
well... to be honest the more obvious problem will be that you won't be testing the RAM, you'll be testing the CPU's cache.. over and over again.
memtest86+ does various magic to basically bypass the caches (by disabling them ;-)...

Doing that in a live kernel situation, and from userspace to boot...... that's... and issue.

--

Are you sure? I always assumed that memtest just used patterns bigger

than L1/L2 caches... ... and IIRC my celeron testing confirmed it, if

I disabled L2 cache in BIOS, memtest behave differently.
Anyway, if you can do iopl(), we may as well let you disable caches,

but you are right, that will need a kernel patch.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

On Wed, 26 Dec 2007 00:09:57 +0100
that's... not nearly usable or enough. Caches are relatively smart

about things like use-once.... and they're huge. 12Mb today. You'd need

patterns bigger than 100Mb to get even close to being reasonably
and a new syscall of some sorts I suspect; "flush all caches" is a ring

0 operation (and you probably need to do it in an ipi anyway on all

cpus)
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

I think that PAT support will help a lot.

How about opening/mmaping /dev/mem, and setting uncacheable attribute there.

Actually it is even possible today with MTRRs.
Regards,

	Maxim Levitsky

--