All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	Matthew Bloch <matthew@bytemark.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: Testing RAM from userspace / question about memmap= arguments
Date: Wed, 26 Dec 2007 22:37:52 +0200	[thread overview]
Message-ID: <200712262237.52818.maximlevitsky@gmail.com> (raw)
In-Reply-To: <20071226021756.7ae9db08@laptopd505.fenrus.org>

В сообщении от Wednesday 26 December 2007 12:17:56 Arjan van de Ven написал(а):
> On Wed, 26 Dec 2007 00:09:57 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > On Sat 2007-12-22 12:09:59, Arjan van de Ven wrote:
> > > On Tue, 18 Dec 2007 17:06:24 +0000
> 
> > > 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...
> 
> 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
> confident that there's nothing left.
> 
> > ... 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.
> 
> 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)
> 

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

  reply	other threads:[~2007-12-26 20:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-12-20 17:01 Siva Prasad

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=200712262237.52818.maximlevitsky@gmail.com \
    --to=maximlevitsky@gmail.com \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@bytemark.co.uk \
    --cc=pavel@ucw.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.