From: Siva Prasad <siva@iitiantech.com>
To: matthew@bytemark.co.uk
Cc: linux-kernel@vger.kernel.org
Subject: Testing RAM from userspace / question about memmap= arguments
Date: Thu, 20 Dec 2007 09:01:31 -0800 [thread overview]
Message-ID: <476A9FEB.2090508@iitiantech.com> (raw)
Hi Matthew,
I worked on some thing similar. For one of our customer product that
goes to defense and security markets, we had to support maximum possible
memory test. We implemented a mechanism of pre-test to test the memory
with walking 1's and 0's just before Linux kernel starts allocating
serious memory for its use. That way, coverage was almost 99%. Once
Linux boots, we do a very through test using various algorithms, however
as you said coverage of memory is little less when we test the system
after Linux boots up completely.
memtest86+ started as a very good alternative, until customer's customer
started complaining about memory issues. Then we had no choice but to
take this route and implement it ourselves from the scratch.
If you want 100% coverage, it may not be possible unless you do it in
BIOS early on. If you take the route of implementing some simple memory
test in Linux kernel before it starts allocating memory, you get very
good % of coverage. Good Luck.
- Siva
Date: Thu, 20 Dec 2007 14:17:10 +0000
From: Matthew Bloch <matthew@bytemark.co.uk>
Subject: Re: Testing RAM from userspace / question about memmap=
arguments
To: linux-kernel@vger.kernel.org
Message-ID: <fkdth6$d7g$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1
Jon Masters wrote:
> On Tue, 2007-12-18 at 17:06 +0000, Matthew Bloch wrote:
>
>> I can see a few potential problems, but since my understanding of the
>> low-level memory mapping is muddy at best, I won't speculate; I'd just
>> appreciate any more expert views on whether this does work, or could be
>> made to work.
>
> Yo,
>
> I don't think your testing approach is thorough enough. Clearly (knowing
> your line of business - as a virtual machine provider), you want to do
> pre-production testing as part of your provisioning. I would suggest
> instead of using mlock() from userspace of simply writing a kernel
> module that does this for every page of available memory.
Yes this is to improve the efficiency of server burn-ins. I would
consider a kernel module, but I still wouldn't be able to test the
memory in which the kernel is sitting, which is my problem. I'm not
sure even a kernel module could reliably test the memory in which it is
residing (memtest86+ relocates itself to do this). Also I don't see how
userspace testing is any less thorough than doing it in the kernel; I
just need a creative way of accessing every single page of memory.
I may do some experiments with the memmap args, some bad RAM and
shuffling it between DIMM sockets when I have the time :)
--
Matthew
next reply other threads:[~2007-12-20 17:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-20 17:01 Siva Prasad [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-12-18 17:06 Testing RAM from userspace / question about memmap= arguments Matthew Bloch
2007-12-20 12:33 ` Jon Masters
2007-12-20 14:17 ` Matthew Bloch
2007-12-21 12:58 ` Pavel Machek
2007-12-22 8:12 ` Richard D
2007-12-22 13:46 ` Pavel Machek
2007-12-22 15:30 ` Richard D
2007-12-22 18:43 ` Pavel Machek
2007-12-22 16:06 ` David Newall
2007-12-22 18:47 ` Pavel Machek
2007-12-22 20:36 ` David Newall
2007-12-22 20:54 ` Pavel Machek
2007-12-23 7:35 ` David Newall
2007-12-23 11:17 ` Pavel Machek
2007-12-22 20:48 ` Matthew Bloch
2007-12-22 20:09 ` Arjan van de Ven
2007-12-25 23:09 ` Pavel Machek
2007-12-26 10:17 ` Arjan van de Ven
2007-12-26 20:37 ` Maxim Levitsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=476A9FEB.2090508@iitiantech.com \
--to=siva@iitiantech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@bytemark.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).