Questions about SMP bootup control
in [Kernel]
|
Prev: early_res: seperate common memmap func from e820.c to fw_memmap.c
Next: The kernel does not start up.
From: Zhu, Yijun (NSN - CN/Beijing) on 21 Mar 2010 22:50 Hi All: I want to do some modification on the SMP architecture. Purpose: Only the first CPU is running the linux OS, while others do some private services processing. My solution: In the end of the start_secondary() function, I try to schedu the slave cpu to call my private endless loop instead of cpu_idle(); Result: The system can NOT up, there is no interactive cli. Question: Is there some wrong with my modification or I go to the wrong way? Thank you very much. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 21 Mar 2010 23:30 "Zhu, Yijun (NSN - CN/Beijing)" <yijun.zhu(a)nsn.com> writes: > Hi All: > > I want to do some modification on the SMP architecture. > > Purpose: > Only the first CPU is running the linux OS, while others do some private > services processing. > > My solution: > In the end of the start_secondary() function, I try to schedu the slave > cpu to call my private endless loop instead of cpu_idle(); > > Result: > The system can NOT up, there is no interactive cli. > > Question: > Is there some wrong with my modification or I go to the wrong way? Presumably you're doing this to own that CPU exclusively. Hooking at cpu_idle is not very useful then because interrupts will be already enabled and the system participate in IPIs etc, so you can't simply disable them, the others will miss them. You would rather need to prevent them from being started in the first place, e.g. by exluding them with maxcpus=.. A better alternative might be to use isolcpus=... and schedule a standard program. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zhu, Yijun (NSN - CN/Beijing) on 22 Mar 2010 03:50
-----Original Message----- From: ext Andi Kleen [mailto:andi(a)firstfloor.org] Sent: Monday, March 22, 2010 11:29 AM To: Zhu, Yijun (NSN - CN/Beijing) Cc: linux-kernel(a)vger.kernel.org; linux-arch(a)vger.kernel.org Subject: Re: Questions about SMP bootup control "Zhu, Yijun (NSN - CN/Beijing)" <yijun.zhu(a)nsn.com> writes: > Hi All: > > I want to do some modification on the SMP architecture. > > Purpose: > Only the first CPU is running the linux OS, while others do some private > services processing. > > My solution: > In the end of the start_secondary() function, I try to schedu the slave > cpu to call my private endless loop instead of cpu_idle(); > > Result: > The system can NOT up, there is no interactive cli. > > Question: > Is there some wrong with my modification or I go to the wrong way? > Presumably you're doing this to own that CPU exclusively. > > Hooking at cpu_idle is not very useful then because interrupts will be > already enabled and the system participate in IPIs etc, so you can't > simply disable them, the others will miss them. > > You would rather need to prevent them from being started in the > first place, e.g. by exluding them with maxcpus=.. > > A better alternative might be to use isolcpus=... and schedule > a standard program. > > -Andi > -- > ak(a)linux.intel.com -- Speaking for myself only. Thank you very much. But when I try to apply with the isolcpus opinion, It seems it still can NOT work. All other CPUs are isolated, only the first one is left. Then I found all others are still initialized by the start_secondary() even I use the isolated opinion, in the end, I add an endless loop instead of cpu_idle(), The system still can NOT up. So is there any mistake in what I did, could someone be kindness to give me more suggestions. Thanks in advance. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |