lkml.org 
[lkml]   [2012]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -mm 4/7] mm: make page colouring code generic
On 06/19/2012 07:27 PM, Andrew Morton wrote:
> On Mon, 18 Jun 2012 18:05:23 -0400
> Rik van Riel<riel@redhat.com> wrote:
>
>> From: Rik van Riel<riel@surriel.com>
>>
>> Fix the x86-64 page colouring code to take pgoff into account.
>
> Could we please have a full description of what's wrong with the
> current code?

Here is a copy of the text I added to the changelog:


The old x86 code will always align the mmap
to aliasing boundaries, even if the program mmaps
the file with a non-zero pgoff.

If program A mmaps the file with pgoff 0, and
program B mmaps the file with pgoff 1. The old
code would align the mmaps, resulting in misaligned
pages:

A: 0123
B: 123

After this patch, they are aligned so the pages
line up:

A: 0123
B: 123

>> Use the x86 and MIPS page colouring code as the basis for a generic
>> page colouring function.

Renamed to "cache alignment", by Andi's request.

>> Teach the generic arch_get_unmapped_area(_topdown) code to call the
>> page colouring code.
>>
>> Make sure that ALIGN_DOWN always aligns down, and ends up at the
>> right page colour.
>
> Some performance tests on the result would be interesting. iirc, we've
> often had trouble demonstrating much or any benefit from coloring.

On AMD Bulldozer, I do not know what the benefits are.

On ARM, MIPS, SPARC and SH, the main benefit is avoiding
data corruption :)

These architectures have VIPT caches on some CPU models,
and MAP_SHARED read-write mappings have to be properly
aligned to guarantee data consistency.



\
 
 \ /
  Last update: 2012-06-21 21:41    [from the cache]
©2003-2011 Jasper Spaans