From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, qiuxishi@huawei.com, dhowells@redhat.com,
daeseok.youn@gmail.com, liuj97@gmail.com, yinghai@kernel.org,
zhangyanfei@cn.fujitsu.com, tangchen@cn.fujitsu.com
Subject: Re: [PATCH V3 2/2] mm/memblock: Add support for excluded memory areas
Date: Tue, 14 Jan 2014 09:24:49 -0500 [thread overview]
Message-ID: <52D548B1.8000504@ti.com> (raw)
In-Reply-To: <52D538FD.8010907@ti.com>
On Tuesday 14 January 2014 08:17 AM, Grygorii Strashko wrote:
> Hi Philipp,
>
> On 01/13/2014 03:03 PM, Philipp Hachtmann wrote:
>> Add a new memory state "nomap" to memblock. This can be used to truncate
>> the usable memory in the system without forgetting about what is really
>> installed.
>
>
> Sorry, but this solution looks a bit complex (and probably wrong - from design point of view))
> if you need just to fix memblock_start_of_DRAM()/memblock_end_of_DRAM() APIs.
>
> More over, other arches use at least below APIs:
> - memblock_is_region_memory() !!!
> - for_each_memblock(memory, reg) !!!
> - __next_mem_pfn_range() !!!
> - memblock_phys_mem_size()
> - memblock_mem_size()
> - memblock_start_of_DRAM()
> - memblock_end_of_DRAM()
> with assumption that "memory" regions array have been updated
> when mem block is stolen (no-mapped), as result this change may
> have unpredictable side effects :( if these new APIs
> will be re-used (for ARM arch, as example).
>
> You can take a look on how ARM is using arm_memblock_steal() -
> the stolen memory is not accounted any more.
>
I was also wondering instead of nomap state, the memblock_add/remove()
will do the same trick. arm_memblock_steal() wrapper does achieve
similar functionality of reserving the DRAM without mapping it into
the Linux. Why not just use the same idea ?
Regards,
Santosh
--
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: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Philipp Hachtmann <phacht@linux.vnet.ibm.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>,
<akpm@linux-foundation.org>, <linux-kernel@vger.kernel.org>,
<linux-mm@kvack.org>, <qiuxishi@huawei.com>,
<dhowells@redhat.com>, <daeseok.youn@gmail.com>,
<liuj97@gmail.com>, <yinghai@kernel.org>,
<zhangyanfei@cn.fujitsu.com>, <tangchen@cn.fujitsu.com>
Subject: Re: [PATCH V3 2/2] mm/memblock: Add support for excluded memory areas
Date: Tue, 14 Jan 2014 09:24:49 -0500 [thread overview]
Message-ID: <52D548B1.8000504@ti.com> (raw)
In-Reply-To: <52D538FD.8010907@ti.com>
On Tuesday 14 January 2014 08:17 AM, Grygorii Strashko wrote:
> Hi Philipp,
>
> On 01/13/2014 03:03 PM, Philipp Hachtmann wrote:
>> Add a new memory state "nomap" to memblock. This can be used to truncate
>> the usable memory in the system without forgetting about what is really
>> installed.
>
>
> Sorry, but this solution looks a bit complex (and probably wrong - from design point of view))
> if you need just to fix memblock_start_of_DRAM()/memblock_end_of_DRAM() APIs.
>
> More over, other arches use at least below APIs:
> - memblock_is_region_memory() !!!
> - for_each_memblock(memory, reg) !!!
> - __next_mem_pfn_range() !!!
> - memblock_phys_mem_size()
> - memblock_mem_size()
> - memblock_start_of_DRAM()
> - memblock_end_of_DRAM()
> with assumption that "memory" regions array have been updated
> when mem block is stolen (no-mapped), as result this change may
> have unpredictable side effects :( if these new APIs
> will be re-used (for ARM arch, as example).
>
> You can take a look on how ARM is using arm_memblock_steal() -
> the stolen memory is not accounted any more.
>
I was also wondering instead of nomap state, the memblock_add/remove()
will do the same trick. arm_memblock_steal() wrapper does achieve
similar functionality of reserving the DRAM without mapping it into
the Linux. Why not just use the same idea ?
Regards,
Santosh
next prev parent reply other threads:[~2014-01-14 14:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 13:03 [PATCH V3 0/2] mm/memblock: Excluded memory, free_all_bootmem Philipp Hachtmann
2014-01-13 13:03 ` Philipp Hachtmann
2014-01-13 13:03 ` [PATCH V3 1/2] mm/nobootmem: free_all_bootmem again Philipp Hachtmann
2014-01-13 13:03 ` Philipp Hachtmann
2014-01-13 13:03 ` [PATCH V3 2/2] mm/memblock: Add support for excluded memory areas Philipp Hachtmann
2014-01-13 13:03 ` Philipp Hachtmann
2014-01-14 0:36 ` Andrew Morton
2014-01-14 0:36 ` Andrew Morton
2014-01-14 9:42 ` Philipp Hachtmann
2014-01-14 9:42 ` Philipp Hachtmann
2014-01-14 22:01 ` Andrew Morton
2014-01-14 22:01 ` Andrew Morton
2014-01-14 13:17 ` Grygorii Strashko
2014-01-14 13:17 ` Grygorii Strashko
2014-01-14 14:24 ` Santosh Shilimkar [this message]
2014-01-14 14:24 ` Santosh Shilimkar
2014-01-14 18:52 ` Philipp Hachtmann
2014-01-14 18:52 ` Philipp Hachtmann
2014-01-17 18:08 ` Strashko, Grygorii
2014-01-17 18:08 ` Strashko, Grygorii
2014-01-17 18:08 ` Strashko, Grygorii
2014-01-20 8:39 ` Philipp Hachtmann
2014-01-20 8:39 ` Philipp Hachtmann
2014-01-20 8:39 ` Philipp Hachtmann
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=52D548B1.8000504@ti.com \
--to=santosh.shilimkar@ti.com \
--cc=akpm@linux-foundation.org \
--cc=daeseok.youn@gmail.com \
--cc=dhowells@redhat.com \
--cc=grygorii.strashko@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuj97@gmail.com \
--cc=phacht@linux.vnet.ibm.com \
--cc=qiuxishi@huawei.com \
--cc=tangchen@cn.fujitsu.com \
--cc=yinghai@kernel.org \
--cc=zhangyanfei@cn.fujitsu.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.