public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Tejun Heo <teheo@novell.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Jan Beulich <JBeulich@novell.com>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: remap allocator for per-CPU memory
Date: Wed, 13 May 2009 13:46:47 +0200	[thread overview]
Message-ID: <20090513114647.GQ19296@one.firstfloor.org> (raw)
In-Reply-To: <4A0AAF10.3030709@novell.com>

> I couldn't find anything explicitly prohibiting PMD/PTE aliases w/
> different attributes although there are plenty of warnings and don'ts
> against giving different attributes to the same linear addresses.  At
> any rate, it definitely looks way too dangerous to depend on.

It is. We've had data corruption because of this in the past.
Worse it's very subtle data corruption, taking a long time
to track down. So yes it's definitely dangerous.
> 
> And, set_memory_*() is basically allowed on any memory allocated via
> get_free_page(), so... we're between rock and hard place.  Looks like

The x86-64 kernel has the text mapping alias which had similar problems.
That was avoided by special casing this.

> remapping partially using large pages is no go.

I'm not sure it was ever a good idea because most CPUs have much less
large TLB entries than small entries. 
(in some cases the difference is dramatic, a few older cores
only had something like 4 2/4MB entries) 
Unless it's really a lot of memory you're talking about here
it's probably better to use small pages for such specific
purposes.

The other issue is that with 1GB pages used in the direct mapping
the problem generally gets much worse. Although luckily it only
hits because there is some dumb kernel code which always forces
smaller pages for GB 0 and 4.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

  reply	other threads:[~2009-05-13 11:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12 15:30 remap allocator for per-CPU memory Jan Beulich
2009-05-12 15:43 ` Tejun Heo
2009-05-13 10:09   ` Tejun Heo
2009-05-13 11:05     ` Andi Kleen
2009-05-13 11:13       ` Tejun Heo
2009-05-13 11:29         ` Tejun Heo
2009-05-13 11:46           ` Andi Kleen [this message]
2009-05-13 12:51           ` Jan Beulich
     [not found]           ` <4A0ADE6A0200007800000BA7@novell.com>
2009-05-13 13:29             ` Tejun Heo
2009-05-13 13:44               ` Jan Beulich
2009-05-13 13:53                 ` Tejun Heo

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=20090513114647.GQ19296@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=JBeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=teheo@novell.com \
    /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