On Wed, Aug 26, 2015 at 1:49 PM, Andrew Morton
wrote:
> On Tue, 25 Aug 2015 22:42:05 -0700 Yinghai Lu wrote:
> I don't know what that means. We have multiple patches under at least
> two different Subject:s. Please be very careful and very specific when
> identifying patches. Otherwise
On Tue, 25 Aug 2015 22:42:05 -0700 Yinghai Lu wrote:
> On Tue, Aug 25, 2015 at 9:17 PM, Ingo Molnar wrote:
> > NAK due to lack of cleanliness: the two loops look almost identical - this
> > sure
> > can be factored out...
>
> Please check complete version at
>
>
On Wed, Aug 26, 2015 at 1:49 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Tue, 25 Aug 2015 22:42:05 -0700 Yinghai Lu ying...@kernel.org wrote:
I don't know what that means. We have multiple patches under at least
two different Subject:s. Please be very careful and very specific when
On Tue, 25 Aug 2015 22:42:05 -0700 Yinghai Lu ying...@kernel.org wrote:
On Tue, Aug 25, 2015 at 9:17 PM, Ingo Molnar mi...@kernel.org wrote:
NAK due to lack of cleanliness: the two loops look almost identical - this
sure
can be factored out...
Please check complete version at
On Tue, Aug 25, 2015 at 9:17 PM, Ingo Molnar wrote:
> NAK due to lack of cleanliness: the two loops look almost identical - this
> sure
> can be factored out...
Please check complete version at
https://patchwork.kernel.org/patch/7074341/
Andrew,
Ingo NAKed raw version of this patch, so you
* Yinghai Lu wrote:
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -390,8 +390,14 @@ int register_mem_sect_under_node(struct memory_block
> *mem_blk, int nid)
> sect_end_pfn = section_nr_to_pfn(mem_blk->end_section_nr);
> sect_end_pfn += PAGES_PER_SECTION - 1;
>
On Tue, Aug 25, 2015 at 12:01 PM, Yinghai Lu wrote:
>> It does ... but this (attached) is simpler. Your patch and mine both
>> allow the system to boot ...
>
> The version that fix with section_nr present checking may save couple
> thousands
> calling to get_nid_for_pfn(). section size /
On Tue, Aug 25, 2015 at 10:03 AM, Tony Luck wrote:
> On Mon, Aug 24, 2015 at 4:59 PM, Yinghai Lu wrote:
>> attached should fix the problem:
>
> It does ... but this (attached) is simpler. Your patch and mine both
> allow the system to boot ...
The version that fix with section_nr present
On Tue, Aug 25, 2015 at 9:17 PM, Ingo Molnar mi...@kernel.org wrote:
NAK due to lack of cleanliness: the two loops look almost identical - this
sure
can be factored out...
Please check complete version at
https://patchwork.kernel.org/patch/7074341/
Andrew,
Ingo NAKed raw version of this
* Yinghai Lu ying...@kernel.org wrote:
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -390,8 +390,14 @@ int register_mem_sect_under_node(struct memory_block
*mem_blk, int nid)
sect_end_pfn = section_nr_to_pfn(mem_blk-end_section_nr);
sect_end_pfn += PAGES_PER_SECTION -
On Tue, Aug 25, 2015 at 10:03 AM, Tony Luck tony.l...@gmail.com wrote:
On Mon, Aug 24, 2015 at 4:59 PM, Yinghai Lu ying...@kernel.org wrote:
attached should fix the problem:
It does ... but this (attached) is simpler. Your patch and mine both
allow the system to boot ...
The version that
On Tue, Aug 25, 2015 at 12:01 PM, Yinghai Lu ying...@kernel.org wrote:
It does ... but this (attached) is simpler. Your patch and mine both
allow the system to boot ...
The version that fix with section_nr present checking may save couple
thousands
calling to get_nid_for_pfn(). section
On Mon, Aug 24, 2015 at 4:41 PM, Yinghai Lu wrote:
> On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck wrote:
>> On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu wrote:
>>
>>> Can you boot with "debug ignore_loglevel" so we can see following print out
>>> for vmemmap?
>>
>> See attached. There are a few
On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck wrote:
> On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu wrote:
>
>> Can you boot with "debug ignore_loglevel" so we can see following print out
>> for vmemmap?
>
> See attached. There are a few extra messages from my own debug printk()
> calls. It seems
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu wrote:
> Can you boot with "debug ignore_loglevel" so we can see following print out
> for vmemmap?
See attached. There are a few extra messages from my own debug printk()
calls. It seems that we successfully deal with node 0 from topology_init()
but
On Mon, Aug 24, 2015 at 1:41 PM, Tony Luck wrote:
> On Mon, Aug 24, 2015 at 10:46 AM, Yinghai Lu wrote:
>> Then, what does the E820 look like?
>
> See attached serial console log of the latest crash
Can you boot with "debug ignore_loglevel" so we can see following print out
for vmemmap?
[
On Mon, Aug 24, 2015 at 10:46 AM, Yinghai Lu wrote:
> Then, what does the E820 look like?
See attached serial console log of the latest crash
-Tony
dmesg
Description: Binary data
On Fri, Aug 21, 2015 at 4:54 PM, Tony Luck wrote:
> On Fri, Aug 21, 2015 at 1:50 PM, Yinghai Lu wrote:
>
> Still stuff going on that I don't understand here. I increased the amount of
> mirrored memory in this machine which moved max_pfn to 0x756
> and probe_memory_block_size() picked 512MB
On Fri, Aug 21, 2015 at 4:54 PM, Tony Luck tony.l...@gmail.com wrote:
On Fri, Aug 21, 2015 at 1:50 PM, Yinghai Lu ying...@kernel.org wrote:
Still stuff going on that I don't understand here. I increased the amount of
mirrored memory in this machine which moved max_pfn to 0x756
and
On Mon, Aug 24, 2015 at 1:41 PM, Tony Luck tony.l...@gmail.com wrote:
On Mon, Aug 24, 2015 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
Then, what does the E820 look like?
See attached serial console log of the latest crash
Can you boot with debug ignore_loglevel so we can see following
On Mon, Aug 24, 2015 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
Then, what does the E820 look like?
See attached serial console log of the latest crash
-Tony
dmesg
Description: Binary data
On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck tony.l...@gmail.com wrote:
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu ying...@kernel.org wrote:
Can you boot with debug ignore_loglevel so we can see following print out
for vmemmap?
See attached. There are a few extra messages from my own debug
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu ying...@kernel.org wrote:
Can you boot with debug ignore_loglevel so we can see following print out
for vmemmap?
See attached. There are a few extra messages from my own debug printk()
calls. It seems that we successfully deal with node 0 from
On Mon, Aug 24, 2015 at 4:41 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck tony.l...@gmail.com wrote:
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu ying...@kernel.org wrote:
Can you boot with debug ignore_loglevel so we can see following print out
for
On Fri, Aug 21, 2015 at 1:50 PM, Yinghai Lu wrote:
>> It seems that many systems with large amounts of memory
>> will have a nicely aligned max_pfn ... so they will get
>> the 2GB block size. If they don't have a well aligned
>> max_pfn, then they need to use a smaller size to avoid
>> the crash
On Fri, Aug 21, 2015 at 1:27 PM, Luck, Tony wrote:
> On Fri, Aug 21, 2015 at 11:38:13AM -0700, Yinghai Lu wrote:
>> That commit could be reverted.
>> According to
>> https://lkml.org/lkml/2014/11/10/123
>
> Do we really need to force the MIN_MEMORY_BLOCK_SIZE on small
> systems?
That is
On Fri, Aug 21, 2015 at 11:38:13AM -0700, Yinghai Lu wrote:
> That commit could be reverted.
> According to
> https://lkml.org/lkml/2014/11/10/123
Do we really need to force the MIN_MEMORY_BLOCK_SIZE on small
systems?
What about this patch - which just uses max_pfn to choose
the block size.
It
On Fri, Aug 21, 2015 at 11:19 AM, Luck, Tony wrote:
> On Tue, Nov 04, 2014 at 04:29:44PM +0800, Daniel J Blueman wrote:
>> On large-memory x86-64 systems of 64GB or more with memory hot-plug
>> enabled, use a 2GB memory block size. Eg with 64GB memory, this reduces
>> the number of directories in
On Tue, Nov 04, 2014 at 04:29:44PM +0800, Daniel J Blueman wrote:
> On large-memory x86-64 systems of 64GB or more with memory hot-plug
> enabled, use a 2GB memory block size. Eg with 64GB memory, this reduces
> the number of directories in /sys/devices/system/memory from 512 to 32,
> making it
On Fri, Aug 21, 2015 at 11:38:13AM -0700, Yinghai Lu wrote:
That commit could be reverted.
According to
https://lkml.org/lkml/2014/11/10/123
Do we really need to force the MIN_MEMORY_BLOCK_SIZE on small
systems?
What about this patch - which just uses max_pfn to choose
the block size.
It
On Fri, Aug 21, 2015 at 1:27 PM, Luck, Tony tony.l...@intel.com wrote:
On Fri, Aug 21, 2015 at 11:38:13AM -0700, Yinghai Lu wrote:
That commit could be reverted.
According to
https://lkml.org/lkml/2014/11/10/123
Do we really need to force the MIN_MEMORY_BLOCK_SIZE on small
systems?
That is
On Tue, Nov 04, 2014 at 04:29:44PM +0800, Daniel J Blueman wrote:
On large-memory x86-64 systems of 64GB or more with memory hot-plug
enabled, use a 2GB memory block size. Eg with 64GB memory, this reduces
the number of directories in /sys/devices/system/memory from 512 to 32,
making it more
On Fri, Aug 21, 2015 at 11:19 AM, Luck, Tony tony.l...@intel.com wrote:
On Tue, Nov 04, 2014 at 04:29:44PM +0800, Daniel J Blueman wrote:
On large-memory x86-64 systems of 64GB or more with memory hot-plug
enabled, use a 2GB memory block size. Eg with 64GB memory, this reduces
the number of
On Fri, Aug 21, 2015 at 1:50 PM, Yinghai Lu ying...@kernel.org wrote:
It seems that many systems with large amounts of memory
will have a nicely aligned max_pfn ... so they will get
the 2GB block size. If they don't have a well aligned
max_pfn, then they need to use a smaller size to avoid
On large-memory x86-64 systems of 64GB or more with memory hot-plug
enabled, use a 2GB memory block size. Eg with 64GB memory, this reduces
the number of directories in /sys/devices/system/memory from 512 to 32,
making it more manageable, and reducing the creation time accordingly.
This caveat is
On large-memory x86-64 systems of 64GB or more with memory hot-plug
enabled, use a 2GB memory block size. Eg with 64GB memory, this reduces
the number of directories in /sys/devices/system/memory from 512 to 32,
making it more manageable, and reducing the creation time accordingly.
This caveat is
36 matches
Mail list logo
