Re: Handling multiple cores by GRUB

[Robert Millan]

On Tue, Oct 13, 2009 at 10:06:59AM +1030, Brendan Trotter wrote:
> Hi,
> 
> On Mon, Oct 12, 2009 at 10:51 PM, Swapnil Pimpale
> <address@hidden> wrote:
> > Actually we are doing an academic project in which we need to have two cores
> > of Intel Core 2 Duo, running inside the GRUB simultaneously. For that we
> > need to send an IPI from primary core to the secondary core.  Can you
> > suggest any pointers to implement this? Has someone done anything similar to
> > this before?
> 
> Is there any sane reason for this? None of GRUB's code is designed for
> multiple CPUs, and I'd assume that no firmware is designed to handle
> multiple CPUs either (I know that "PC BIOS" isn't), and I expect that
> if you wasted your time and got multiple CPUs running inside GRUB then
> one of the CPUs would do everything while any extra CPU/s would do
> nothing (until an OS is started and you need to shut down the "do
> nothing" CPU/s).

I don't buy the idea of GRUB having multi-thread;  we're a bootloader,
not the kernel of an OS.  However, support for multiple CPUs could be
useful if we treat secondary CPUs as a co-processor (i.e. without
preemption) and sync with it the same way we do with other hardware,
e.g.:

  int end = 0;
  void foo () { do_stuff1 ();  end = 1; }
  do_stuff_in_cpu2 (foo);
  do_stuff2 ();
  while (! end);

But I don't think this would be desireable except in very specific situations,
and I'm not sure which ones.  Perhaps loading a compressed file would be an
example (so that uncompression and disk poll can be done in parallel).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."