Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Boris Ostrovsky
On 04/20/2017 12:15 PM, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: >>> This is getting ludicrous. Xen is plain broken, and instead of fixing >>> it, you propose to somehow deal with its obviously crack induced >>> behaviour :-( >> Totally agree and I

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Boris Ostrovsky
On 04/20/2017 12:15 PM, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: >>> This is getting ludicrous. Xen is plain broken, and instead of fixing >>> it, you propose to somehow deal with its obviously crack induced >>> behaviour :-( >> Totally agree and I

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Andrew Cooper
On 20/04/17 16:06, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Andrew Cooper
On 20/04/17 16:06, Peter Zijlstra wrote: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Vitaly Kuznetsov
Boris Ostrovsky writes: > On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: In this patch I suggest we set __max_logical_packages based on the

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Vitaly Kuznetsov
Boris Ostrovsky writes: > On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: In this patch I suggest we set __max_logical_packages based on the max_physical_pkg_id and total_cpus, >>> So my

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Peter Zijlstra
On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: > > This is getting ludicrous. Xen is plain broken, and instead of fixing > > it, you propose to somehow deal with its obviously crack induced > > behaviour :-( > > Totally agree and I don't like the solution I propose (and that's

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Peter Zijlstra
On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote: > > This is getting ludicrous. Xen is plain broken, and instead of fixing > > it, you propose to somehow deal with its obviously crack induced > > behaviour :-( > > Totally agree and I don't like the solution I propose (and that's

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Boris Ostrovsky
On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote: > Peter Zijlstra writes: > >> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >>> In this patch I suggest we set __max_logical_packages based on the >>> max_physical_pkg_id and total_cpus, >> So my 4 socket

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Boris Ostrovsky
On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote: > Peter Zijlstra writes: > >> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >>> In this patch I suggest we set __max_logical_packages based on the >>> max_physical_pkg_id and total_cpus, >> So my 4 socket 144 CPU system will then

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Vitaly Kuznetsov
Peter Zijlstra writes: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, >

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Vitaly Kuznetsov
Peter Zijlstra writes: > On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: >> In this patch I suggest we set __max_logical_packages based on the >> max_physical_pkg_id and total_cpus, > > So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, > instead of 4. > >

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Peter Zijlstra
On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: > In this patch I suggest we set __max_logical_packages based on the > max_physical_pkg_id and total_cpus, So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, instead of 4. This wastes quite a bit of memory for

Re: [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Peter Zijlstra
On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote: > In this patch I suggest we set __max_logical_packages based on the > max_physical_pkg_id and total_cpus, So my 4 socket 144 CPU system will then get max_physical_pkg_id=144, instead of 4. This wastes quite a bit of memory for

[PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Vitaly Kuznetsov
Recent changes in logical package management (Commit 9d85eb9119f4 ("x86/smpboot: Make logical package management more robust") and its predecessor) caused boot failures for some Xen guests. E.g. I'm trying to boot 10 CPU guest on AMD Opteron 4284 system and I see the following crash: [

[PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

2017-04-20 Thread Vitaly Kuznetsov
Recent changes in logical package management (Commit 9d85eb9119f4 ("x86/smpboot: Make logical package management more robust") and its predecessor) caused boot failures for some Xen guests. E.g. I'm trying to boot 10 CPU guest on AMD Opteron 4284 system and I see the following crash: [