Hi,
>> That's a good point and it would probably work for attachment of cpus,
but
>> it won't work for detachment because there are some data structures that
>> need to be updated if a cpu gets detached. For example it would be nice
>> [...]
>> So at least for detaching it would make sense to
> That's a good point and it would probably work for attachment of cpus, but
> it won't work for detachment because there are some data structures that
> need to be updated if a cpu gets detached. For example it would be nice
> to flush the per-cpu cache of the detached cpu in the slabcache. The
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote:
> Hi,
>
> >> I still wonder what you and other people think about the idea of an
> >> interface where the parts of the kernel with per-cpu dependencies should
> >> register two functions...
> >Why not compile kernel with structeres big enough for 32
Hi,
>> I still wonder what you and other people think about the idea of an
>> interface where the parts of the kernel with per-cpu dependencies should
>> register two functions...
>Why not compile kernel with structeres big enough for 32 processors,
>and then just add CPUs up to the limit wit
Hi!
> I still wonder what you and other people think about the idea of an
> interface where the parts of the kernel with per-cpu dependencies should
> register two functions...
Why not compile kernel with structeres big enough for 32 processors,
and then just add CPUs up to the limit without cha
> thanks for your input but I think it won't work this way because the value
> of smp_num_cpus needs to be increased by one right before a new cpu gets
> started. Then one can imagine the following situation at one of the cpus
> that needs to be captured:
This is fine providing the code is aware
>> sigp. To synchronize n CPUs one can create n kernel threads and give
>> them a high priority to make sure they will be executed soon (e.g. by
>> setting p->policy to SCHED_RR and p->rt_priority to a very high
>> value). As soon as all CPUs are in synchronized state (with
>> interrupts disab
On Mon, 11 Dec 2000 15:03:47 [EMAIL PROTECTED] wrote:
>
> Recently I had some thoughts on how to realise CPU attachment and
> detachment in a running Linux system (based on the 2.4 kernel).
>
> CPU attachment and detachment would make sense on an S/390 when there
> are several Linuxes running,
<[EMAIL PROTECTED]>
>Sent: Monday, December 11, 2000 9:03 AM
>Subject: CPU attachent and detachment in a running Linux system
[snip]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Heiko,
If I'm not mistaken, this sort of thing has been done by the beowulf folks.
Matthew D. Pitts
[EMAIL PROTECTED]
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 9:03 AM
Subject: CPU attachent and detachment i
Recently I had some thoughts on how to realise CPU attachment and
detachment in a running Linux system (based on the 2.4 kernel).
CPU attachment and detachment would make sense on an S/390 when there
are several Linuxes running, each in its own logical partition. This
way a CPU could be taken
11 matches
Mail list logo
