Hi, Thanks Gavin, and all others for your quick answers. I looked into the psradm commmand, especially p_online looks interesting.
Just as a note: I'm not interested in disabling a processor permanently, just temporarely, so it seems like p_online could help me notify the OS that no interrupts should be sent to the (temporarely) disabled processor. I'll try this approach in the near future. Thanks again. Mladen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: den 1 december 2006 10:21 To: Mladen Nikitovic Cc: [email protected] Subject: Re: [osol-code] disable processor(s) Mladen Nikitovic wrote: > Hi, > > I would like to disable one or several processors dynamically in a SMP > system running openSolaris 10. My experience so far (using a full system simulator) is that disabling the processor (from the simulator-side) causes "kernel panic" in the OS - probably because it is not aware that the processor isn't available anymore. > > Is there a way to make the OS aware of this? Also, is it possible to > re-route interrupt(s) so that a sleeping processor does not receive > them, instead they are bypassed to a currently active processor? You cannot simply evaporate a cpu without preparing the OS for the event - it will panic, as you have found. As a first step you can psradm(1m) or p_online(2) to idle the cpu. This means it runs only the idle loop and a small amount of other unavoidable work (like cross traps for mmu demaps) - "offline" in this sense simply means that no routine work is dispatched to it. Once quiesced in the above sense some platforms have the additional ability to actually remove the processor resource. These are all the DR (dynamic reconfiguration) hooks you'll see around this code. The trick is to drive the cpu out of the coherence domain by flushing its cache and keeping it clean and then electrically isolating it from the domain or otherwise causing it to evaporate from the OS point of view. In sun4u DR the cache clean is performed by jumping to code that runs out of an sram local to the cpu board (ie not from main memory) and which is uncacheable; that code can flush the main cache without itself bringing in new lines - a delicate dance, nonetheless. With the advent of hypervisors this stuff becomes more relevant to everday platforms - the evaporation occurs in a virtualized sense. Cheers Gavin _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
