Skip to contentSkip to conversation

NUMA Hotplug emulator

PATCH Superseded Shaohui Zheng 2 participants 5 messages Nov 16, 2010 1 message not in the archive x86

v2 of 9 Superseded Latest is v9 →

lore
Share & tools
lore

Shaohui Zheng

author
#0 lore raw

PATCH v2 5/8 NUMA Hotplug emulator

Quoted 3 lines

This looks like an incredibly painful interface. How about scrapping all of this _emu() mess and just reworking the register_cpu() interface? Something like:

hi, Paul
I saw your reply on patchwork.kernel.org, but I did not find your email
in my mailbox, you might forget to cc to me.

I think that your register_cpu_node interface seems good, but this will
remove the interface register_cpu. it is not the original purpose of the emulator, we want to emulate the oringal process, but we did not want to change the old interface, that is a rule.

I want to share some piece of codes, and I did not want to do so much change,
so I call register_cpu and register_cpu_emu in the same function. yes, it is a painful interface, I will add a function arch_register_cpu_emu to solve it.

Real hotplug process:
arch_register_cpu
- call register_cpu

Emulated hotplug process:
arch_register_cpu_emu
- call register_cpu_emu

arch/x86/kernel/topology.c +10 -0
index 7e45159..93859d5 100644
@@ -52,6 +52,16 @@ int __ref arch_register_cpu(int num)
 }
 EXPORT_SYMBOL(arch_register_cpu);
 
+/* emulated version for arch_register_cpu */
+int __ref arch_register_cpu_emu(int num, int nid)
+{
+	if (num)
+		per_cpu(cpu_devices, num).cpu.hotpluggable = 1;
+
+	return register_cpu_emu(&per_cpu(cpu_devices, num).cpu, nid);
+}
+EXPORT_SYMBOL(arch_register_cpu_emu);
+
 void arch_unregister_cpu(int num)
 {
 	unregister_cpu(&per_cpu(cpu_devices, num).cpu);
Signature · 2 lines
Thanks & Regards,
Shaohui
#1 lore raw
Quoted 8 lines · Shaohui Zheng
Quoted 3 lines

This looks like an incredibly painful interface. How about scrapping all of this _emu() mess and just reworking the register_cpu() interface? Something like:

hi, Paul
I saw your reply on patchwork.kernel.org, but I did not find your email
in my mailbox, you might forget to cc to me.

Then fix your mailer. You are presently forcing Mail-Followup-To to the list, which in turn is dropping you from the cc on a group reply.

Quoted 5 lines

I think that your register_cpu_node interface seems good, but this will
remove the interface register_cpu. it is not the original purpose of the emulator, we want to emulate the oringal process, but we did not want to change the old interface, that is a rule.

Wait, what? How does my patch remove register_cpu()? It does no such thing, all it does is add a supplemental register_cpu_node() for you to call in to, without needing to carry any of the _emu() damage around. The old interface has not been modified in any way whatsoever.

A message that is not in the archive (sent off-list or not yet received): A24AE1FFE7AEC5489F83450EE98351BF27D53BCC36@shsmsx502.ccr.corp.intel.com

author
#3 lore raw
Quoted 6 lines · Shaohui Zheng
Quoted 4 lines
Quoted 3 lines

This looks like an incredibly painful interface. How about scrapping all of this _emu() mess and just reworking the register_cpu() interface? Something like:

Quoted 6 lines
Quoted 4 lines

hi, Paul
I saw your reply on patchwork.kernel.org, but I did not find your email
in my mailbox, you might forget to cc to me.

Then fix your mailer. You are presently forcing Mail-Followup-To to the list, which in turn is dropping you from the cc on a group reply.

My mailer is mutt, and I did not configure "Mail-Follow-To", it should use the default value. I add "set followup_to=no" to my ~/muttrc file now.

Hope it is got fixed, thanks you for your remind.

Quoted 10 lines
Quoted 6 lines

I think that your register_cpu_node interface seems good, but this will
remove the interface register_cpu. it is not the original purpose of the emulator, we want to emulate the oringal process, but we did not want to change the old interface, that is a rule.

Wait, what? How does my patch remove register_cpu()? It does no such thing, all it does is add a supplemental register_cpu_node() for you to call in to, without needing to carry any of the _emu() damage around. The old interface has not been modified in any way whatsoever.

I recheck your patch, It seems that I misunderstand it. with your function register_cpu_node, we can call it in arch_cpu_probe, and then we need not the _emu() any more. Our _emu() functions work, but it get thing complicated. :)

I will rework patch 4 and patch 5 with your suggestion, thanks.

Signature · 2 lines
Thanks & Regards,
Shaohui
#4 lore raw
Quoted 10 lines · Shaohui Zheng
Quoted 10 lines · Shaohui Zheng
Quoted 8 lines
Quoted 3 lines

This looks like an incredibly painful interface. How about scrapping all of this _emu() mess and just reworking the register_cpu() interface? Something like:

hi, Paul
I saw your reply on patchwork.kernel.org, but I did not find your email
in my mailbox, you might forget to cc to me.

Quoted 8 lines
Quoted 2 lines

Then fix your mailer. You are presently forcing Mail-Followup-To to the list, which in turn is dropping you from the cc on a group reply.

My mailer is mutt, and I did not configure "Mail-Follow-To", it should use the default value. I add "set followup_to=no" to my ~/muttrc file now.

Hope it is got fixed, thanks you for your remind.

Yes, it's fixed now!

Quoted 10 lines
Quoted 9 lines
Quoted 5 lines

I think that your register_cpu_node interface seems good, but this will
remove the interface register_cpu. it is not the original purpose of the emulator, we want to emulate the oringal process, but we did not want to change the old interface, that is a rule.

Wait, what? How does my patch remove register_cpu()? It does no such thing, all it does is add a supplemental register_cpu_node() for you to call in to, without needing to carry any of the _emu() damage around. The old interface has not been modified in any way whatsoever.

Quoted 6 lines

I recheck your patch, It seems that I misunderstand it. with your function register_cpu_node, we can call it in arch_cpu_probe, and then we need not the _emu() any more. Our _emu() functions work, but it get thing complicated. :)

I will rework patch 4 and patch 5 with your suggestion, thanks.

Perhaps the easiest is just to insert my patch in to your series as a standalone thing and then build on top of it for your patches 4 and 5. If you wish to do this, then you can of course add my Signed-off-by for that.

Also, are you doing this development in a git tree somewhere? I'd like to get it going on top of SH also, so it would be nice to have a point of reference for keeping things in sync (otherwise I'll just make a topic branch with your newest version and send you updates incrementally).

author
#5 lore raw
Quoted 9 lines

Perhaps the easiest is just to insert my patch in to your series as a standalone thing and then build on top of it for your patches 4 and 5. If you wish to do this, then you can of course add my Signed-off-by for that.

Also, are you doing this development in a git tree somewhere? I'd like to get it going on top of SH also, so it would be nice to have a point of reference for keeping things in sync (otherwise I'll just make a topic branch with your newest version and send you updates incrementally).

It is an internal project, so we did not have a public git tree. it is available in internal only.

the purpose of the emulator is just for CPU/Memory hotplug debuging, there are a lot of hotplug issues before linux kernel 2.6.32, it is very hard to debug. With the help of emuatlor, we get them fixed, so we think the emulator is a good tool, and we want to share it with more people.

Signature · 2 lines
Thanks & Regards,
Shaohui