From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Alex Thorlton <athorlton@sgi.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
linux-snps-arc@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [PATCH 1/2] mm,thp: refactor generic deposit/withdraw routines for wider usage
Date: Thu, 11 Feb 2016 17:59:34 +0530 [thread overview]
Message-ID: <56BC7EAE.7070206@synopsys.com> (raw)
In-Reply-To: <20160211122023.6d719513@mschwide>
On Thursday 11 February 2016 04:50 PM, Martin Schwidefsky wrote:
> On Thu, 11 Feb 2016 16:23:33 +0530
> Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
>> On Thursday 11 February 2016 03:52 PM, Martin Schwidefsky wrote:
>>> On Thu, 11 Feb 2016 14:58:26 +0530
>>> Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>>>
>>>> Generic pgtable_trans_huge_deposit()/pgtable_trans_huge_withdraw()
>>>> assume pgtable_t to be struct page * which is not true for all arches.
>>>> Thus arc, s390, sparch end up with their own copies despite no special
>>>> hardware requirements (unlike powerpc).
>>>
>>> s390 does have a special hardware requirement. pgtable_t is an address
>>> for a 2K block of memory. It is *not* equivalent to a struct page *
>>> which refers to a 4K block of memory. That has been the whole point
>>> to introduce pgtable_t.
>>
>> Actually my reference to hardware requirement was more like powerpc style save a
>> hash value some where etc.
>>
>> Now pgtable_t need not be struct page * even if the actual sizes are same - e.g.
>> in ARC port I kept pgtable_t as pte_t * simply to avoid a few page_address() calls
>> in mm code (you could argue that is was a micro-optimization, anyways..)
>>
>> So given I know nothing about s390 MMU internals, I still think you can switch to
>> the update generic version despite 2K vs. 4K. Agree ?
>
> No, we can not. For s390 a page table is aligned on a 2K boundary and is
> only half the size of a page (except for KVM but that is another story).
> For s390 a pgtable_t is a pointer to the memory location with the 256 ptes
> and not a struct page *.
>
> The cast "struct page *new = (struct page*)pgtable;" in your first patch
> is already broken, "new" points to the memory of the page table and
> the list_head operations will clobber that memory.
The current s390 code does something similar using a different struct cast. It is
still writing in pgtable_t - although at a different location.
> You try to fix it up
> with the memset to zero in pgtable_trans_huge_withdraw but that does not
> correct the pte entries for s390 as an invalid page-table entry is *not*
> all zeros.
Right so that is the problem - just trying to understand.
> In short, please let s390 keep its own copy of deposit/withdraw.
You got it - I'm out of the way :-)
Thx,
-Vineet
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 1/2] mm,thp: refactor generic deposit/withdraw routines for wider usage
Date: Thu, 11 Feb 2016 17:59:34 +0530 [thread overview]
Message-ID: <56BC7EAE.7070206@synopsys.com> (raw)
In-Reply-To: <20160211122023.6d719513@mschwide>
On Thursday 11 February 2016 04:50 PM, Martin Schwidefsky wrote:
> On Thu, 11 Feb 2016 16:23:33 +0530
> Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
>> On Thursday 11 February 2016 03:52 PM, Martin Schwidefsky wrote:
>>> On Thu, 11 Feb 2016 14:58:26 +0530
>>> Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>>>
>>>> Generic pgtable_trans_huge_deposit()/pgtable_trans_huge_withdraw()
>>>> assume pgtable_t to be struct page * which is not true for all arches.
>>>> Thus arc, s390, sparch end up with their own copies despite no special
>>>> hardware requirements (unlike powerpc).
>>>
>>> s390 does have a special hardware requirement. pgtable_t is an address
>>> for a 2K block of memory. It is *not* equivalent to a struct page *
>>> which refers to a 4K block of memory. That has been the whole point
>>> to introduce pgtable_t.
>>
>> Actually my reference to hardware requirement was more like powerpc style save a
>> hash value some where etc.
>>
>> Now pgtable_t need not be struct page * even if the actual sizes are same - e.g.
>> in ARC port I kept pgtable_t as pte_t * simply to avoid a few page_address() calls
>> in mm code (you could argue that is was a micro-optimization, anyways..)
>>
>> So given I know nothing about s390 MMU internals, I still think you can switch to
>> the update generic version despite 2K vs. 4K. Agree ?
>
> No, we can not. For s390 a page table is aligned on a 2K boundary and is
> only half the size of a page (except for KVM but that is another story).
> For s390 a pgtable_t is a pointer to the memory location with the 256 ptes
> and not a struct page *.
>
> The cast "struct page *new = (struct page*)pgtable;" in your first patch
> is already broken, "new" points to the memory of the page table and
> the list_head operations will clobber that memory.
The current s390 code does something similar using a different struct cast. It is
still writing in pgtable_t - although at a different location.
> You try to fix it up
> with the memset to zero in pgtable_trans_huge_withdraw but that does not
> correct the pte entries for s390 as an invalid page-table entry is *not*
> all zeros.
Right so that is the problem - just trying to understand.
> In short, please let s390 keep its own copy of deposit/withdraw.
You got it - I'm out of the way :-)
Thx,
-Vineet
next prev parent reply other threads:[~2016-02-11 12:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 9:28 [PATCH 0/2] Enable s390/arc/sparc to use generic thp deposit/withdraw Vineet Gupta
2016-02-11 9:28 ` Vineet Gupta
2016-02-11 9:28 ` [PATCH 1/2] mm,thp: refactor generic deposit/withdraw routines for wider usage Vineet Gupta
2016-02-11 9:28 ` [PATCH 1/2] mm, thp: " Vineet Gupta
2016-02-11 10:22 ` [PATCH 1/2] mm,thp: " Martin Schwidefsky
2016-02-11 10:22 ` Martin Schwidefsky
2016-02-11 10:22 ` Martin Schwidefsky
2016-02-11 10:22 ` Martin Schwidefsky
2016-02-11 10:53 ` Vineet Gupta
2016-02-11 10:53 ` Vineet Gupta
2016-02-11 11:20 ` Martin Schwidefsky
2016-02-11 11:20 ` Martin Schwidefsky
2016-02-11 11:20 ` Martin Schwidefsky
2016-02-11 11:20 ` Martin Schwidefsky
2016-02-11 12:29 ` Vineet Gupta [this message]
2016-02-11 12:29 ` Vineet Gupta
2016-02-11 9:28 ` [PATCH 2/2] ARC: mm: THP: use generic THP deposit/withdraw Vineet Gupta
2016-02-11 9:28 ` Vineet Gupta
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=56BC7EAE.7070206@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=athorlton@sgi.com \
--cc=davem@davemloft.net \
--cc=gerald.schaefer@de.ibm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=schwidefsky@de.ibm.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.