Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1664741 > unrolled thread
| Started by | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| First post | 2017-06-13 12:50 +0200 |
| Last post | 2017-06-14 15:50 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc Michael Ellerman <mpe@ellerman.id.au> - 2017-06-13 12:50 +0200
Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc Michael Bringmann <mwb@linux.vnet.ibm.com> - 2017-06-14 00:30 +0200
Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc Balbir Singh <bsingharora@gmail.com> - 2017-06-14 07:30 +0200
Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc Michael Bringmann <mwb@linux.vnet.ibm.com> - 2017-06-14 15:50 +0200
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2017-06-13 12:50 +0200 |
| Subject | Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc |
| Message-ID | <tRRyx-6SG-11@gated-at.bofh.it> |
Michael Bringmann <mwb@linux.vnet.ibm.com> writes:
> Here is the information from 2 different kernels. I have not been able to retrieve
> the information matching yesterday's attachments, yet, as those dumps were
> acquired in April.
>
> Attached please find 2 dumps of similar material from kernels running with my
> current patches (Linux 4.4, Linux 4.12).
OK thanks.
I'd actually like to see the dmesg output from a kernel *without* your
patches.
Looking at the device tree properties:
ltcalpine2-lp9:/proc/device-tree/ibm,dynamic-reconfiguration-memory # lsprop ibm,associativity-lookup-arrays
ibm,associativity-lookup-arrays
00000004 = 4 arrays
00000004 = of 4 entries each
00000000 00000000 00000000 00000000
00000000 00000000 00000001 00000001
00000000 00000003 00000006 00000006
00000000 00000003 00000007 00000007
Which does tell us that nodes 0, 1, 6 and 7 exist.
So your idea of looking at that and setting any node found in there
online should work.
My only worry is that behaviour appears to be completely undocumented in
PAPR, ie. PAPR explicitly says that property only needs to contain
values for LMBs present at boot.
But possibly we can talk to the PowerVM/PAPR guys and have that changed
so that it becomes something we can rely on.
cheers
[toc] | [next] | [standalone]
| From | Michael Bringmann <mwb@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-06-14 00:30 +0200 |
| Subject | Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc |
| Message-ID | <tS2tX-5hx-5@gated-at.bofh.it> |
| In reply to | #1664741 |
On a related note, we are discussing the addition of 2 new device-tree properties with Pete Heyrman and his fellows that should simplify the determination of the set of required nodes. * One property would provide the total/max number of nodes needed by the kernel on the current hardware. * A second property would provide the total/max number of nodes that the kernel could use on any system to which it could be migrated. These properties aren't available, yet, and it takes time to define new properties in the PAPR and have them implemented in pHyp and the kernel. As an intermediary step, the systems which are doing a lot of dynamic hot-add/hot-remove configuration could provide equivalent information to the PowerPC kernel with a command line parameter. The 'numa.c' code would then read this value and fill in the necessary entries in the 'node_possible_map'. Would you foresee any problems with using such a feature? Thanks. On 06/13/2017 05:45 AM, Michael Ellerman wrote: > Michael Bringmann <mwb@linux.vnet.ibm.com> writes: > >> Here is the information from 2 different kernels. I have not been able to retrieve >> the information matching yesterday's attachments, yet, as those dumps were >> acquired in April. >> >> Attached please find 2 dumps of similar material from kernels running with my >> current patches (Linux 4.4, Linux 4.12). > > OK thanks. > > I'd actually like to see the dmesg output from a kernel *without* your > patches. > > Looking at the device tree properties: > > ltcalpine2-lp9:/proc/device-tree/ibm,dynamic-reconfiguration-memory # lsprop ibm,associativity-lookup-arrays > ibm,associativity-lookup-arrays > 00000004 = 4 arrays > 00000004 = of 4 entries each > 00000000 00000000 00000000 00000000 > 00000000 00000000 00000001 00000001 > 00000000 00000003 00000006 00000006 > 00000000 00000003 00000007 00000007 > > > Which does tell us that nodes 0, 1, 6 and 7 exist. > > So your idea of looking at that and setting any node found in there > online should work. > > My only worry is that behaviour appears to be completely undocumented in > PAPR, ie. PAPR explicitly says that property only needs to contain > values for LMBs present at boot. > > But possibly we can talk to the PowerVM/PAPR guys and have that changed > so that it becomes something we can rely on. > > cheers > > -- Michael W. Bringmann Linux Technology Center IBM Corporation Tie-Line 363-5196 External: (512) 286-5196 Cell: (512) 466-0650 mwb@linux.vnet.ibm.com
[toc] | [prev] | [next] | [standalone]
| From | Balbir Singh <bsingharora@gmail.com> |
|---|---|
| Date | 2017-06-14 07:30 +0200 |
| Subject | Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc |
| Message-ID | <tS92q-11P-9@gated-at.bofh.it> |
| In reply to | #1665257 |
On Wed, Jun 14, 2017 at 3:25 PM, Balbir Singh <bsingharora@gmail.com> wrote: > > > On Wed, Jun 14, 2017 at 8:21 AM, Michael Bringmann <mwb@linux.vnet.ibm.com> > wrote: >> >> On a related note, we are discussing the addition of 2 new device-tree >> properties >> with Pete Heyrman and his fellows that should simplify the determination >> of the >> set of required nodes. >> >> * One property would provide the total/max number of nodes needed by the >> kernel >> on the current hardware. > > Yes, that would be nice to have > >> >> * A second property would provide the total/max number of nodes that the >> kernel >> could use on any system to which it could be migrated. >> > Not sure about this one, are you suggesting more memory can be added depending on the migration target? > > >> >> These properties aren't available, yet, and it takes time to define new >> properties >> in the PAPR and have them implemented in pHyp and the kernel. As an >> intermediary >> step, the systems which are doing a lot of dynamic hot-add/hot-remove >> configuration >> could provide equivalent information to the PowerPC kernel with a command >> line >> parameter. The 'numa.c' code would then read this value and fill in the >> necessary >> entries in the 'node_possible_map'. >> >> Would you foresee any problems with using such a feature? > > Sorry my mailer goofed up, resending Balbir Singh
[toc] | [prev] | [next] | [standalone]
| From | Michael Bringmann <mwb@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-06-14 15:50 +0200 |
| Subject | Re: RESEND Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc |
| Message-ID | <tSgQi-5OL-35@gated-at.bofh.it> |
| In reply to | #1665431 |
Hello: On 06/14/2017 12:27 AM, Balbir Singh wrote: > On Wed, Jun 14, 2017 at 3:25 PM, Balbir Singh <bsingharora@gmail.com> wrote: >> >> >> On Wed, Jun 14, 2017 at 8:21 AM, Michael Bringmann <mwb@linux.vnet.ibm.com> >> wrote: >>> >>> On a related note, we are discussing the addition of 2 new device-tree >>> properties >>> with Pete Heyrman and his fellows that should simplify the determination >>> of the >>> set of required nodes. >>> >>> * One property would provide the total/max number of nodes needed by the >>> kernel >>> on the current hardware. >> >> > > Yes, that would be nice to have > >> >>> >>> * A second property would provide the total/max number of nodes that the >>> kernel >>> could use on any system to which it could be migrated. >>> >> > > Not sure about this one, are you suggesting more memory can be added > depending on the migration target? We would use only one of these numbers to allocate nodes. I have only been on the periphery of the discussions, so I can not communicate the full reasoning as to why both measures would be needed. We would like to have the first number for node allocation/initialization, but if only the second value were provided, we would likely need to use it. >> >> >>> >>> These properties aren't available, yet, and it takes time to define new >>> properties >>> in the PAPR and have them implemented in pHyp and the kernel. As an >>> intermediary >>> step, the systems which are doing a lot of dynamic hot-add/hot-remove >>> configuration >>> could provide equivalent information to the PowerPC kernel with a command >>> line >>> parameter. The 'numa.c' code would then read this value and fill in the >>> necessary >>> entries in the 'node_possible_map'. >>> >>> Would you foresee any problems with using such a feature? >> >> > > Sorry my mailer goofed up, resending > > Balbir Singh > Thanks. -- Michael W. Bringmann Linux Technology Center IBM Corporation Tie-Line 363-5196 External: (512) 286-5196 Cell: (512) 466-0650 mwb@linux.vnet.ibm.com
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web