remap allocator for per-CPU memory

remap allocator for per-CPU memory

[Jan Beulich]

Didn't the addition of this allocator introduce another case that needs special
treatment in pageattr.c? Since large pages are used for mapping the allocated
memory, but only part of the initially allocated large pages are actually
retained, there's now the potential for TLB aliases with different cache
attributes for those parts of these pages that get passed back through
free_bootmem().

Jan

Re: remap allocator for per-CPU memory

[Tejun Heo]

Jan Beulich wrote:
> Didn't the addition of this allocator introduce another case that
> needs special treatment in pageattr.c? Since large pages are used
> for mapping the allocated memory, but only part of the initially
> allocated large pages are actually retained, there's now the
> potential for TLB aliases with different cache attributes for those
> parts of these pages that get passed back through free_bootmem().

Hmmm.... yes, the large page mapping and the returned part of it would
alias each other.  What changes should be made for it?  Dunno much
about how pageattr works.

Thanks.

-- 
tejun

Re: remap allocator for per-CPU memory

[Tejun Heo]

Tejun Heo wrote:
> Jan Beulich wrote:
>> Didn't the addition of this allocator introduce another case that
>> needs special treatment in pageattr.c? Since large pages are used
>> for mapping the allocated memory, but only part of the initially
>> allocated large pages are actually retained, there's now the
>> potential for TLB aliases with different cache attributes for those
>> parts of these pages that get passed back through free_bootmem().
> 
> Hmmm.... yes, the large page mapping and the returned part of it would
> alias each other.  What changes should be made for it?  Dunno much
> about how pageattr works.

Okay, just glanced over the pageattr code.  I don't think we need any
special provisions for this as long as the TLB is fine with having
overlapping PMD and PTE mappings with different attributes (please
note that these two mappings aren't occupying the same linear
addresses - they're aliases).  This is allowed, right?

Thanks.

-- 
tejun

Re: remap allocator for per-CPU memory

[Andi Kleen]

Tejun Heo <teheo@novell.com> writes:
>
> Okay, just glanced over the pageattr code.  I don't think we need any
> special provisions for this as long as the TLB is fine with having
> overlapping PMD and PTE mappings with different attributes (please
> note that these two mappings aren't occupying the same linear
> addresses - they're aliases).  This is allowed, right?

Nope.

-Andi

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

Re: remap allocator for per-CPU memory

[Tejun Heo]

Andi Kleen wrote:
> Tejun Heo <teheo@novell.com> writes:
>> Okay, just glanced over the pageattr code.  I don't think we need any
>> special provisions for this as long as the TLB is fine with having
>> overlapping PMD and PTE mappings with different attributes (please
>> note that these two mappings aren't occupying the same linear
>> addresses - they're aliases).  This is allowed, right?
> 
> Nope.

Yeah, I'm going through the manual now and can't find anything which
allows such behavior.  I haven't been able to find anything which
describes what happens between large page and 4k page aliases.
Aieee...  I'll dig through the manual a bit more and see whether this
can be worked around somehow.  :-(

Thanks.

-- 
tejun

Re: remap allocator for per-CPU memory

[Tejun Heo]

Tejun Heo wrote:
> Andi Kleen wrote:
>> Tejun Heo <teheo@novell.com> writes:
>>> Okay, just glanced over the pageattr code.  I don't think we need any
>>> special provisions for this as long as the TLB is fine with having
>>> overlapping PMD and PTE mappings with different attributes (please
>>> note that these two mappings aren't occupying the same linear
>>> addresses - they're aliases).  This is allowed, right?
>> Nope.
> 
> Yeah, I'm going through the manual now and can't find anything which
> allows such behavior.  I haven't been able to find anything which
> describes what happens between large page and 4k page aliases.
> Aieee...  I'll dig through the manual a bit more and see whether this
> can be worked around somehow.  :-(

Looks like we're screwed.

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.

And, set_memory_*() is basically allowed on any memory allocated via
get_free_page(), so... we're between rock and hard place.  Looks like
remapping partially using large pages is no go.

Any ideas?

Thanks.

-- 
tejun

Re: remap allocator for per-CPU memory

[Andi Kleen]

> 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.

Re: remap allocator for per-CPU memory

[Jan Beulich]

>>> Tejun Heo <teheo@novell.com> 13.05.09 13:29 >>>
>Tejun Heo wrote:
>> Andi Kleen wrote:
>>> Tejun Heo <teheo@novell.com> writes:
>>>> Okay, just glanced over the pageattr code.  I don't think we need any
>>>> special provisions for this as long as the TLB is fine with having
>>>> overlapping PMD and PTE mappings with different attributes (please
>>>> note that these two mappings aren't occupying the same linear
>>>> addresses - they're aliases).  This is allowed, right?
>>> Nope.
>> 
>> Yeah, I'm going through the manual now and can't find anything which
>> allows such behavior.  I haven't been able to find anything which
>>> describes what happens between large page and 4k page aliases.
>> Aieee...  I'll dig through the manual a bit more and see whether this
>> can be worked around somehow.  :-(
>
>Looks like we're screwed.
>
>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.
>
>And, set_memory_*() is basically allowed on any memory allocated via
>get_free_page(), so... we're between rock and hard place.  Looks like
>remapping partially using large pages is no go.
>
>Any ideas?

I think the only two alternatives are

(a) don't use large pages in the first place here, or

(b) teach the pageattr code to handle the per-CPU virtual area similarly to
the kernel space for x86-64 (though it's going to be a little more complicated
since there's no pre-determined relation between the virtual and physical
addresses - the necessary lookup might become expensive on systems with
very many [possible] CPUs).

Jan

Re: remap allocator for per-CPU memory

[Tejun Heo]

Hello,

Jan Beulich wrote:
> I think the only two alternatives are
> 
> (a) don't use large pages in the first place here, or

Seems like the first candidate at the moment.

> (b) teach the pageattr code to handle the per-CPU virtual area similarly to
> the kernel space for x86-64 (though it's going to be a little more complicated
> since there's no pre-determined relation between the virtual and physical
> addresses - the necessary lookup might become expensive on systems with
> very many [possible] CPUs).

Can you elaborate this a bit?  Let's sya there's quick way to match
whether the page is part of the remapped large page, what can pageattr
do differently then?  Applying the same attribute to both mappings?
Failing or filtering set_memory_*()?

Thanks.

-- 
tejun

Re: remap allocator for per-CPU memory

[Jan Beulich]

>>> Tejun Heo <teheo@novell.com> 13.05.09 15:29 >>>
>> (b) teach the pageattr code to handle the per-CPU virtual area similarly to
>> the kernel space for x86-64 (though it's going to be a little more complicated
>> since there's no pre-determined relation between the virtual and physical
>> addresses - the necessary lookup might become expensive on systems with
>> very many [possible] CPUs).
>
>Can you elaborate this a bit?  Let's sya there's quick way to match
>whether the page is part of the remapped large page, what can pageattr
>do differently then?  Applying the same attribute to both mappings?
>Failing or filtering set_memory_*()?

It would have to split the page. Perhaps there wouldn't be a need to apply the
new attribute to the page(s) that is(are) in the process of getting its(their)
attribute(s) changed; instead, just don't re-establish a 4k mapping for those
pages that aren't part of the per-CPU space.

And of course, the request should fail when it targets one of the pages that
are actually part of the per-CPU space -- but would be a BUG() anyway.

Jan

Re: remap allocator for per-CPU memory

[Tejun Heo]

Hello, Jan.

Jan Beulich wrote:
>>>> Tejun Heo <teheo@novell.com> 13.05.09 15:29 >>>
>>> (b) teach the pageattr code to handle the per-CPU virtual area similarly to
>>> the kernel space for x86-64 (though it's going to be a little more complicated
>>> since there's no pre-determined relation between the virtual and physical
>>> addresses - the necessary lookup might become expensive on systems with
>>> very many [possible] CPUs).
>> Can you elaborate this a bit?  Let's sya there's quick way to match
>> whether the page is part of the remapped large page, what can pageattr
>> do differently then?  Applying the same attribute to both mappings?
>> Failing or filtering set_memory_*()?
> 
> It would have to split the page. Perhaps there wouldn't be a need to
> apply the new attribute to the page(s) that is(are) in the process
> of getting its(their) attribute(s) changed; instead, just don't
> re-establish a 4k mapping for those pages that aren't part of the
> per-CPU space.

Ah... right.  Splitting the remapped area should do the trick, so now
the question is whether it would worth all the trouble or should we
just forget about remapping and use 4k on NUMA machines.  I don't have
much clue here.  Andi seems to think there's no reason to bother with
PMD mappings.  Ingo, what do you think?

Thanks.

-- 
tejun