All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: David Rientjes <rientjes@google.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-mips@linux-mips.org, linux-xtensa@linux-xtensa.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/highmem: make kmap cache coloring aware
Date: Mon, 21 Jul 2014 18:14:41 -0700	[thread overview]
Message-ID: <53CDBB01.7040007@imgtec.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407211754350.7042@chino.kir.corp.google.com>

On 07/21/2014 05:58 PM, David Rientjes wrote:
> On Thu, 17 Jul 2014, Max Filippov wrote:
>
>> From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>>
>> Provide hooks that allow architectures with aliasing cache to align
>> mapping address of high pages according to their color. Such architectures
>> may enforce similar coloring of low- and high-memory page mappings and
>> reuse existing cache management functions to support highmem.
>>
> Typically a change like this would be proposed along with a change to an
> architecture which would define this new ARCH_PKMAP_COLORING and have its
> own overriding definitions.  Based on who you sent this patch to, it looks
> like that would be mips and xtensa.  Now the only question is where are
> those patches to add the alternate definitions for those platforms?
Yes, there is one, at least for MIPS. This stuff can be a common ground 
for both platforms (MIPS and XTENSA)

>
>> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>> [ Max: extract architecture-independent part of the original patch, clean
>>    up checkpatch and build warnings. ]
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> Changes v1->v2:
>> - fix description
>>
>>   mm/highmem.c | 19 ++++++++++++++++---
>>   1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/highmem.c b/mm/highmem.c
>> index b32b70c..6898a8b 100644
>> --- a/mm/highmem.c
>> +++ b/mm/highmem.c
>> @@ -44,6 +44,14 @@ DEFINE_PER_CPU(int, __kmap_atomic_idx);
>>    */
>>   #ifdef CONFIG_HIGHMEM
>>   
>> +#ifndef ARCH_PKMAP_COLORING
>> +#define set_pkmap_color(pg, cl)		/* */
> This is typically done with do {} while (0).
>
>> +#define get_last_pkmap_nr(p, cl)	(p)
>> +#define get_next_pkmap_nr(p, cl)	(((p) + 1) & LAST_PKMAP_MASK)
>> +#define is_no_more_pkmaps(p, cl)	(!(p))
> That's not gramatically proper.
>
>> +#define get_next_pkmap_counter(c, cl)	((c) - 1)
>> +#endif
>> +
>>   unsigned long totalhigh_pages __read_mostly;
>>   EXPORT_SYMBOL(totalhigh_pages);
>>   
>> @@ -161,19 +169,24 @@ static inline unsigned long map_new_virtual(struct page *page)
>>   {
>>   	unsigned long vaddr;
>>   	int count;
>> +	int color __maybe_unused;
>> +
>> +	set_pkmap_color(page, color);
>> +	last_pkmap_nr = get_last_pkmap_nr(last_pkmap_nr, color);
>>   
>>   start:
>>   	count = LAST_PKMAP;
>>   	/* Find an empty entry */
>>   	for (;;) {
>> -		last_pkmap_nr = (last_pkmap_nr + 1) & LAST_PKMAP_MASK;
>> -		if (!last_pkmap_nr) {
>> +		last_pkmap_nr = get_next_pkmap_nr(last_pkmap_nr, color);
>> +		if (is_no_more_pkmaps(last_pkmap_nr, color)) {
>>   			flush_all_zero_pkmaps();
>>   			count = LAST_PKMAP;
>>   		}
>>   		if (!pkmap_count[last_pkmap_nr])
>>   			break;	/* Found a usable entry */
>> -		if (--count)
>> +		count = get_next_pkmap_counter(count, color);
> And that's not equivalent at all, --count decrements the auto variable and
> then tests it for being non-zero.  Your get_next_pkmap_counter() never
> decrements count.
David, the statements

             count = get_next_pkmap_counter(count, color);
             if (count > 0)

are extended in STANDARD (non colored) case to

             count = (count - 1);
             if (count > 0)

which are perfect equivalent of

             if (--count)

>
>> +		if (count > 0)
>>   			continue;
>>   
>>   		/*

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: David Rientjes <rientjes@google.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>, <linux-mm@kvack.org>,
	<linux-arch@vger.kernel.org>, <linux-mips@linux-mips.org>,
	<linux-xtensa@linux-xtensa.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] mm/highmem: make kmap cache coloring aware
Date: Mon, 21 Jul 2014 18:14:41 -0700	[thread overview]
Message-ID: <53CDBB01.7040007@imgtec.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407211754350.7042@chino.kir.corp.google.com>

On 07/21/2014 05:58 PM, David Rientjes wrote:
> On Thu, 17 Jul 2014, Max Filippov wrote:
>
>> From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>>
>> Provide hooks that allow architectures with aliasing cache to align
>> mapping address of high pages according to their color. Such architectures
>> may enforce similar coloring of low- and high-memory page mappings and
>> reuse existing cache management functions to support highmem.
>>
> Typically a change like this would be proposed along with a change to an
> architecture which would define this new ARCH_PKMAP_COLORING and have its
> own overriding definitions.  Based on who you sent this patch to, it looks
> like that would be mips and xtensa.  Now the only question is where are
> those patches to add the alternate definitions for those platforms?
Yes, there is one, at least for MIPS. This stuff can be a common ground 
for both platforms (MIPS and XTENSA)

>
>> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>> [ Max: extract architecture-independent part of the original patch, clean
>>    up checkpatch and build warnings. ]
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> Changes v1->v2:
>> - fix description
>>
>>   mm/highmem.c | 19 ++++++++++++++++---
>>   1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/highmem.c b/mm/highmem.c
>> index b32b70c..6898a8b 100644
>> --- a/mm/highmem.c
>> +++ b/mm/highmem.c
>> @@ -44,6 +44,14 @@ DEFINE_PER_CPU(int, __kmap_atomic_idx);
>>    */
>>   #ifdef CONFIG_HIGHMEM
>>   
>> +#ifndef ARCH_PKMAP_COLORING
>> +#define set_pkmap_color(pg, cl)		/* */
> This is typically done with do {} while (0).
>
>> +#define get_last_pkmap_nr(p, cl)	(p)
>> +#define get_next_pkmap_nr(p, cl)	(((p) + 1) & LAST_PKMAP_MASK)
>> +#define is_no_more_pkmaps(p, cl)	(!(p))
> That's not gramatically proper.
>
>> +#define get_next_pkmap_counter(c, cl)	((c) - 1)
>> +#endif
>> +
>>   unsigned long totalhigh_pages __read_mostly;
>>   EXPORT_SYMBOL(totalhigh_pages);
>>   
>> @@ -161,19 +169,24 @@ static inline unsigned long map_new_virtual(struct page *page)
>>   {
>>   	unsigned long vaddr;
>>   	int count;
>> +	int color __maybe_unused;
>> +
>> +	set_pkmap_color(page, color);
>> +	last_pkmap_nr = get_last_pkmap_nr(last_pkmap_nr, color);
>>   
>>   start:
>>   	count = LAST_PKMAP;
>>   	/* Find an empty entry */
>>   	for (;;) {
>> -		last_pkmap_nr = (last_pkmap_nr + 1) & LAST_PKMAP_MASK;
>> -		if (!last_pkmap_nr) {
>> +		last_pkmap_nr = get_next_pkmap_nr(last_pkmap_nr, color);
>> +		if (is_no_more_pkmaps(last_pkmap_nr, color)) {
>>   			flush_all_zero_pkmaps();
>>   			count = LAST_PKMAP;
>>   		}
>>   		if (!pkmap_count[last_pkmap_nr])
>>   			break;	/* Found a usable entry */
>> -		if (--count)
>> +		count = get_next_pkmap_counter(count, color);
> And that's not equivalent at all, --count decrements the auto variable and
> then tests it for being non-zero.  Your get_next_pkmap_counter() never
> decrements count.
David, the statements

             count = get_next_pkmap_counter(count, color);
             if (count > 0)

are extended in STANDARD (non colored) case to

             count = (count - 1);
             if (count > 0)

which are perfect equivalent of

             if (--count)

>
>> +		if (count > 0)
>>   			continue;
>>   
>>   		/*

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: David Rientjes <rientjes@google.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-mips@linux-mips.org, linux-xtensa@linux-xtensa.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/highmem: make kmap cache coloring aware
Date: Mon, 21 Jul 2014 18:14:41 -0700	[thread overview]
Message-ID: <53CDBB01.7040007@imgtec.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1407211754350.7042@chino.kir.corp.google.com>

On 07/21/2014 05:58 PM, David Rientjes wrote:
> On Thu, 17 Jul 2014, Max Filippov wrote:
>
>> From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>>
>> Provide hooks that allow architectures with aliasing cache to align
>> mapping address of high pages according to their color. Such architectures
>> may enforce similar coloring of low- and high-memory page mappings and
>> reuse existing cache management functions to support highmem.
>>
> Typically a change like this would be proposed along with a change to an
> architecture which would define this new ARCH_PKMAP_COLORING and have its
> own overriding definitions.  Based on who you sent this patch to, it looks
> like that would be mips and xtensa.  Now the only question is where are
> those patches to add the alternate definitions for those platforms?
Yes, there is one, at least for MIPS. This stuff can be a common ground 
for both platforms (MIPS and XTENSA)

>
>> Signed-off-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
>> [ Max: extract architecture-independent part of the original patch, clean
>>    up checkpatch and build warnings. ]
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> Changes v1->v2:
>> - fix description
>>
>>   mm/highmem.c | 19 ++++++++++++++++---
>>   1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/highmem.c b/mm/highmem.c
>> index b32b70c..6898a8b 100644
>> --- a/mm/highmem.c
>> +++ b/mm/highmem.c
>> @@ -44,6 +44,14 @@ DEFINE_PER_CPU(int, __kmap_atomic_idx);
>>    */
>>   #ifdef CONFIG_HIGHMEM
>>   
>> +#ifndef ARCH_PKMAP_COLORING
>> +#define set_pkmap_color(pg, cl)		/* */
> This is typically done with do {} while (0).
>
>> +#define get_last_pkmap_nr(p, cl)	(p)
>> +#define get_next_pkmap_nr(p, cl)	(((p) + 1) & LAST_PKMAP_MASK)
>> +#define is_no_more_pkmaps(p, cl)	(!(p))
> That's not gramatically proper.
>
>> +#define get_next_pkmap_counter(c, cl)	((c) - 1)
>> +#endif
>> +
>>   unsigned long totalhigh_pages __read_mostly;
>>   EXPORT_SYMBOL(totalhigh_pages);
>>   
>> @@ -161,19 +169,24 @@ static inline unsigned long map_new_virtual(struct page *page)
>>   {
>>   	unsigned long vaddr;
>>   	int count;
>> +	int color __maybe_unused;
>> +
>> +	set_pkmap_color(page, color);
>> +	last_pkmap_nr = get_last_pkmap_nr(last_pkmap_nr, color);
>>   
>>   start:
>>   	count = LAST_PKMAP;
>>   	/* Find an empty entry */
>>   	for (;;) {
>> -		last_pkmap_nr = (last_pkmap_nr + 1) & LAST_PKMAP_MASK;
>> -		if (!last_pkmap_nr) {
>> +		last_pkmap_nr = get_next_pkmap_nr(last_pkmap_nr, color);
>> +		if (is_no_more_pkmaps(last_pkmap_nr, color)) {
>>   			flush_all_zero_pkmaps();
>>   			count = LAST_PKMAP;
>>   		}
>>   		if (!pkmap_count[last_pkmap_nr])
>>   			break;	/* Found a usable entry */
>> -		if (--count)
>> +		count = get_next_pkmap_counter(count, color);
> And that's not equivalent at all, --count decrements the auto variable and
> then tests it for being non-zero.  Your get_next_pkmap_counter() never
> decrements count.
David, the statements

             count = get_next_pkmap_counter(count, color);
             if (count > 0)

are extended in STANDARD (non colored) case to

             count = (count - 1);
             if (count > 0)

which are perfect equivalent of

             if (--count)

>
>> +		if (count > 0)
>>   			continue;
>>   
>>   		/*

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-07-22  1:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 17:03 [PATCH v2] mm/highmem: make kmap cache coloring aware Max Filippov
2014-07-17 17:03 ` Max Filippov
2014-07-22  0:58 ` David Rientjes
2014-07-22  0:58   ` David Rientjes
2014-07-22  1:14   ` Leonid Yegoshin [this message]
2014-07-22  1:14     ` Leonid Yegoshin
2014-07-22  1:14     ` Leonid Yegoshin
2014-07-22  1:20     ` David Rientjes
2014-07-22  1:20       ` David Rientjes
2014-07-22  9:44   ` Max Filippov
2014-07-22  9:44     ` Max Filippov
2014-07-23 21:17 ` Andrew Morton
2014-07-23 21:17   ` Andrew Morton
2014-07-24  0:38   ` Max Filippov
2014-07-24  0:38     ` Max Filippov
2014-07-24 22:21     ` Andrew Morton
2014-07-24 22:21       ` Andrew Morton
2014-07-25  2:12       ` Leonid Yegoshin
2014-07-25  2:12         ` Leonid Yegoshin

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=53CDBB01.7040007@imgtec.com \
    --to=leonid.yegoshin@imgtec.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=rientjes@google.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 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.