All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 0/5] Huge pages for short descriptors on ARM
Date: Thu, 24 Apr 2014 11:36:39 +0100	[thread overview]
Message-ID: <20140424103639.GC19564@arm.com> (raw)
In-Reply-To: <20140424102229.GA28014@linaro.org>

Hi Steve,

On Thu, Apr 24, 2014 at 11:22:29AM +0100, Steve Capper wrote:
> On Wed, Apr 16, 2014 at 12:46:38PM +0100, Steve Capper wrote:
> Just a ping on this...
> 
> I would really like to get huge page support for short descriptors on
> ARM merged as I've been carrying around these patches for a long time.
> 
> Recently I've had no issues raised about the code. The patches have
> been tested and found to be both beneficial to system performance and
> stable.
> 
> There are two parts to the series, the first patch is a core mm/ patch
> that introduces some huge_pte_ helper functions that allows for a much
> simpler ARM (without LPAE) implementation. The second part is the
> actual arch/arm code.
> 
> I'm not sure how to proceed with these patches. I was thinking that
> they could be picked up into linux-next? If that sounds reasonable;
> Andrew, would you like to take the mm/ patch and Russell could you
> please take the arch/arm patches?
> 
> Also, I was hoping to get these into 3.16. Are there any objections to
> that?

Who is asking for this code? We already support hugepages for LPAE systems,
so this would be targetting what? A9? I'm reluctant to add ~400 lines of
subtle, low-level mm code to arch/arm/ if it doesn't have any active users.

I guess I'm after some commitment that this is (a) useful to somebody and
(b) going to be tested regularly, otherwise it will go the way of things
like big-endian, where we end up carrying around code which is broken more
often than not (although big-endian is more self-contained).

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Steve Capper <steve.capper@linaro.org>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"robherring2@gmail.com" <robherring2@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"gerald.schaefer@de.ibm.com" <gerald.schaefer@de.ibm.com>
Subject: Re: [PATCH V2 0/5] Huge pages for short descriptors on ARM
Date: Thu, 24 Apr 2014 11:36:39 +0100	[thread overview]
Message-ID: <20140424103639.GC19564@arm.com> (raw)
In-Reply-To: <20140424102229.GA28014@linaro.org>

Hi Steve,

On Thu, Apr 24, 2014 at 11:22:29AM +0100, Steve Capper wrote:
> On Wed, Apr 16, 2014 at 12:46:38PM +0100, Steve Capper wrote:
> Just a ping on this...
> 
> I would really like to get huge page support for short descriptors on
> ARM merged as I've been carrying around these patches for a long time.
> 
> Recently I've had no issues raised about the code. The patches have
> been tested and found to be both beneficial to system performance and
> stable.
> 
> There are two parts to the series, the first patch is a core mm/ patch
> that introduces some huge_pte_ helper functions that allows for a much
> simpler ARM (without LPAE) implementation. The second part is the
> actual arch/arm code.
> 
> I'm not sure how to proceed with these patches. I was thinking that
> they could be picked up into linux-next? If that sounds reasonable;
> Andrew, would you like to take the mm/ patch and Russell could you
> please take the arch/arm patches?
> 
> Also, I was hoping to get these into 3.16. Are there any objections to
> that?

Who is asking for this code? We already support hugepages for LPAE systems,
so this would be targetting what? A9? I'm reluctant to add ~400 lines of
subtle, low-level mm code to arch/arm/ if it doesn't have any active users.

I guess I'm after some commitment that this is (a) useful to somebody and
(b) going to be tested regularly, otherwise it will go the way of things
like big-endian, where we end up carrying around code which is broken more
often than not (although big-endian is more self-contained).

Will

--
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: Will Deacon <will.deacon@arm.com>
To: Steve Capper <steve.capper@linaro.org>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"robherring2@gmail.com" <robherring2@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"gerald.schaefer@de.ibm.com" <gerald.schaefer@de.ibm.com>
Subject: Re: [PATCH V2 0/5] Huge pages for short descriptors on ARM
Date: Thu, 24 Apr 2014 11:36:39 +0100	[thread overview]
Message-ID: <20140424103639.GC19564@arm.com> (raw)
In-Reply-To: <20140424102229.GA28014@linaro.org>

Hi Steve,

On Thu, Apr 24, 2014 at 11:22:29AM +0100, Steve Capper wrote:
> On Wed, Apr 16, 2014 at 12:46:38PM +0100, Steve Capper wrote:
> Just a ping on this...
> 
> I would really like to get huge page support for short descriptors on
> ARM merged as I've been carrying around these patches for a long time.
> 
> Recently I've had no issues raised about the code. The patches have
> been tested and found to be both beneficial to system performance and
> stable.
> 
> There are two parts to the series, the first patch is a core mm/ patch
> that introduces some huge_pte_ helper functions that allows for a much
> simpler ARM (without LPAE) implementation. The second part is the
> actual arch/arm code.
> 
> I'm not sure how to proceed with these patches. I was thinking that
> they could be picked up into linux-next? If that sounds reasonable;
> Andrew, would you like to take the mm/ patch and Russell could you
> please take the arch/arm patches?
> 
> Also, I was hoping to get these into 3.16. Are there any objections to
> that?

Who is asking for this code? We already support hugepages for LPAE systems,
so this would be targetting what? A9? I'm reluctant to add ~400 lines of
subtle, low-level mm code to arch/arm/ if it doesn't have any active users.

I guess I'm after some commitment that this is (a) useful to somebody and
(b) going to be tested regularly, otherwise it will go the way of things
like big-endian, where we end up carrying around code which is broken more
often than not (although big-endian is more self-contained).

Will

  reply	other threads:[~2014-04-24 10:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 11:46 [PATCH V2 0/5] Huge pages for short descriptors on ARM Steve Capper
2014-04-16 11:46 ` Steve Capper
2014-04-16 11:46 ` Steve Capper
2014-04-16 11:46 ` [PATCH V2 1/5] mm: hugetlb: Introduce huge_pte_{page,present,young} Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46 ` [PATCH V2 2/5] arm: mm: Adjust the parameters for __sync_icache_dcache Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46 ` [PATCH V2 3/5] arm: mm: Make mmu_gather aware of huge pages Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46 ` [PATCH V2 4/5] arm: mm: HugeTLB support for non-LPAE systems Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46 ` [PATCH V2 5/5] arm: mm: Add Transparent HugePage support for non-LPAE Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-16 11:46   ` Steve Capper
2014-04-24 10:22 ` [PATCH V2 0/5] Huge pages for short descriptors on ARM Steve Capper
2014-04-24 10:22   ` Steve Capper
2014-04-24 10:22   ` Steve Capper
2014-04-24 10:36   ` Will Deacon [this message]
2014-04-24 10:36     ` Will Deacon
2014-04-24 10:36     ` Will Deacon
2014-04-24 10:42     ` Russell King - ARM Linux
2014-04-24 10:42       ` Russell King - ARM Linux
2014-04-24 10:42       ` Russell King - ARM Linux
2014-04-24 10:46       ` Will Deacon
2014-04-24 10:46         ` Will Deacon
2014-04-24 10:46         ` Will Deacon
2014-04-24 10:55       ` Steve Capper
2014-04-24 10:55         ` Steve Capper
2014-04-24 10:55         ` Steve Capper
2014-04-24 11:03         ` Russell King - ARM Linux
2014-04-24 11:03           ` Russell King - ARM Linux
2014-04-24 11:03           ` Russell King - ARM Linux
2014-04-24 12:03           ` Steve Capper
2014-04-24 12:03             ` Steve Capper
2014-04-24 12:03             ` Steve Capper
2014-06-03  0:27           ` Grazvydas Ignotas
2014-06-03  0:27             ` Grazvydas Ignotas
2014-06-03  0:27             ` Grazvydas Ignotas
2014-04-24 13:33     ` Rob Herring
2014-04-24 13:33       ` Rob Herring
2014-04-24 13:33       ` Rob Herring

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=20140424103639.GC19564@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.