[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Handling multiple cores by GRUB
From: |
Robert Millan |
Subject: |
Re: Handling multiple cores by GRUB |
Date: |
Wed, 14 Oct 2009 18:46:24 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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."