linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>,
	"Strashko, Grygorii" <grygorii.strashko@ti.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] ARM: mm: Fix the memblock allocation for LPAE machines
Date: Wed, 5 Feb 2014 23:48:15 +0000	[thread overview]
Message-ID: <20140205234815.GU26684@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <52F2CBC0.3030305@ti.com>

On Wed, Feb 05, 2014 at 06:39:44PM -0500, Santosh Shilimkar wrote:
> Russell,
> 
> On Saturday 01 February 2014 03:14 PM, Santosh Shilimkar wrote:
> > Commit ad6492b8 added much needed memblock_virt_alloc_low() and further
> > commit 07bacb3 {memblock, bootmem: restore goal for alloc_low} fixed the
> > issue with low memory limit thansk to Yinghai. But even after all these fixes,
> > there is still one case where the limit check done with ARCH_LOW_ADDRESS_LIMIT
> > for low memory fails. Russell pointed out the issue with 32 bit LPAE machines
> > in below thread.
> > 	https://lkml.org/lkml/2014/1/28/364
> > 
> > Since on some LPAE machines where memory start address is beyond 4GB,
> > the low memory marker in memblock will be set to default
> > ARCH_LOW_ADDRESS_LIMIT which is wrong. We can fix this by letting
> > architectures set the ARCH_LOW_ADDRESS_LIMIT using another export
> > similar to memblock_set_current_limit() but am not sure whether
> > its worth the trouble. Tell me if you think otherwise.
> > 
> > Rather am just trying to fix that one broken case using memblock_virt_alloc()
> > in setup code since the memblock.current_limit is updated appropriately
> > makes it work on all ARM 32 bit machines.
> > 
> > Cc: Yinghai Lu <yinghai@kernel.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Strashko, Grygorii <grygorii.strashko@ti.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > ---
> Whats you say here ? We should get the fix for the
> issue. If you are ok, I can drop the patch in patch system.

Is this still an issue, or has Tejun fixed it by some other means?  I've not
noticed anything being broken at the moment.

Can you confirm whether we still have an issue without this patch please?

Thanks.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

  reply	other threads:[~2014-02-05 23:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-01 20:14 [PATCH] ARM: mm: Fix the memblock allocation for LPAE machines Santosh Shilimkar
2014-02-05 23:39 ` Santosh Shilimkar
2014-02-05 23:48   ` Russell King - ARM Linux [this message]
2014-02-06  0:50     ` Santosh Shilimkar
2014-02-06 18:41       ` Russell King - ARM Linux
2014-02-06 18:51         ` Santosh Shilimkar

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=20140205234815.GU26684@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).