On 10/22/2012 06:18 PM, Borislav Petkov wrote:
On Mon, Oct 22, 2012 at 11:33:16AM +0800, Tang Chen wrote:
I have 2 nodes, node0 and node1. node1 could be hotpluged.
node0 has cpu0 ~ cpu15, node1 has cpu16 ~ cpu31.
I online all the cpus on node1, and hot-remove node1 directly.
Hold on, I need
On Mon, Oct 22, 2012 at 11:33:16AM +0800, Tang Chen wrote:
> I have 2 nodes, node0 and node1. node1 could be hotpluged.
> node0 has cpu0 ~ cpu15, node1 has cpu16 ~ cpu31.
>
> I online all the cpus on node1, and hot-remove node1 directly.
Hold on, I need to ask here: you soft-online all cores on
On Mon, Oct 22, 2012 at 11:33:16AM +0800, Tang Chen wrote:
I have 2 nodes, node0 and node1. node1 could be hotpluged.
node0 has cpu0 ~ cpu15, node1 has cpu16 ~ cpu31.
I online all the cpus on node1, and hot-remove node1 directly.
Hold on, I need to ask here: you soft-online all cores on
On 10/22/2012 06:18 PM, Borislav Petkov wrote:
On Mon, Oct 22, 2012 at 11:33:16AM +0800, Tang Chen wrote:
I have 2 nodes, node0 and node1. node1 could be hotpluged.
node0 has cpu0 ~ cpu15, node1 has cpu16 ~ cpu31.
I online all the cpus on node1, and hot-remove node1 directly.
Hold on, I need
On 10/20/2012 01:21 AM, Luck, Tony wrote:
In this case, the following BUG_ON in try_to_wake_up_local() will be triggered:
BUG_ON(rq != this_rq());
Logically this looks OK - what is the test case to trigger this? I've done a
moderate
amount of testing of cpu online/offline while injecting
On 10/20/2012 01:21 AM, Luck, Tony wrote:
In this case, the following BUG_ON in try_to_wake_up_local() will be triggered:
BUG_ON(rq != this_rq());
Logically this looks OK - what is the test case to trigger this? I've done a
moderate
amount of testing of cpu online/offline while injecting
> In this case, the following BUG_ON in try_to_wake_up_local() will be
> triggered:
> BUG_ON(rq != this_rq());
Logically this looks OK - what is the test case to trigger this? I've done a
moderate
amount of testing of cpu online/offline while injecting corrected errors (when
testing
the CMCI
On Fri, Oct 19, 2012 at 01:45:28PM +0800, Tang Chen wrote:
> cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
> running cpu, and migrate itself to the dest cpu. But worker processes are not
> allowed to be migrated. If current is a worker, the worker will be migrated
On Fri, Oct 19, 2012 at 01:45:28PM +0800, Tang Chen wrote:
cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
running cpu, and migrate itself to the dest cpu. But worker processes are not
allowed to be migrated. If current is a worker, the worker will be migrated to
In this case, the following BUG_ON in try_to_wake_up_local() will be
triggered:
BUG_ON(rq != this_rq());
Logically this looks OK - what is the test case to trigger this? I've done a
moderate
amount of testing of cpu online/offline while injecting corrected errors (when
testing
the CMCI
cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
running cpu, and migrate itself to the dest cpu. But worker processes are not
allowed to be migrated. If current is a worker, the worker will be migrated to
another cpu, but the corresponding worker_pool is still on the
cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
running cpu, and migrate itself to the dest cpu. But worker processes are not
allowed to be migrated. If current is a worker, the worker will be migrated to
another cpu, but the corresponding worker_pool is still on the
12 matches
Mail list logo
