On Thu, 18 Feb 2016, Thomas Gleixner wrote:
> So there is a limitation to BIOS creativity and all we need is to maintain a
> logical package id.
Just for the record. This driver would fall apart today if the socket ids
would be > 7. The uncore extra PCI devs assume a fixed mapping between the
phys
On Thu, 18 Feb 2016, Thomas Gleixner wrote:
> On Thu, 18 Feb 2016, Peter Zijlstra wrote:
> > On Wed, Feb 17, 2016 at 11:16:40PM +0100, Andi Kleen wrote:
> > > > Do you have any data to back that up or is that just "believe" ?
> > >
> > > I've seen systems with discontiguous apic ids before.
> > >
Stephane,
On Thu, 18 Feb 2016, Stephane Eranian wrote:
> On Thu, Feb 18, 2016 at 12:13 AM, Peter Zijlstra wrote:
> > Now clearly, BIOS can completely wreck things and indeed report too
> > small an apic_id range or whatever, and in this case we're up a creek
> > without a paddle.
> >
> > But I th
On Thu, 18 Feb 2016, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 11:16:40PM +0100, Andi Kleen wrote:
> > > Do you have any data to back that up or is that just "believe" ?
> >
> > I've seen systems with discontiguous apic ids before.
> >
> > It is obvious if you consider setups with node hotp
On Thu, Feb 18, 2016 at 01:35:56AM -0800, Stephane Eranian wrote:
> But let's assume that the BIOS does some weird mappings and that the
> id for socket0 is indeed 0
> but for socket1 it is 255. Then doing:
Right, that would be fail. But Andi was talking about physical hotplug,
and that should wor
On Thu, Feb 18, 2016 at 12:13 AM, Peter Zijlstra wrote:
>
> On Wed, Feb 17, 2016 at 11:16:40PM +0100, Andi Kleen wrote:
> > > Do you have any data to back that up or is that just "believe" ?
> >
> > I've seen systems with discontiguous apic ids before.
> >
> > It is obvious if you consider setups
On Wed, Feb 17, 2016 at 11:16:40PM +0100, Andi Kleen wrote:
> > Do you have any data to back that up or is that just "believe" ?
>
> I've seen systems with discontiguous apic ids before.
>
> It is obvious if you consider setups with node hotplug.
Those systems will also have a num_possible_cpus(
* Andi Kleen wrote:
> > Do you have any data to back that up or is that just "believe" ?
>
> I've seen systems with discontiguous apic ids before.
>
> It is obvious if you consider setups with node hotplug.
>
> BTW reading this thread you don't seem interested in any code review
> feedback,
On Wed, 17 Feb 2016, Andi Kleen wrote:
> > Do you have any data to back that up or is that just "believe" ?
>
> I've seen systems with discontiguous apic ids before.
>
> It is obvious if you consider setups with node hotplug.
Right, but if you have 1024 maximal cores and
> BTW reading this t
> Do you have any data to back that up or is that just "believe" ?
I've seen systems with discontiguous apic ids before.
It is obvious if you consider setups with node hotplug.
BTW reading this thread you don't seem interested in any code review feedback,
attacking everyone, not bothering to loo
On Wed, 17 Feb 2016, Andi Kleen wrote:
> Stephane Eranian writes:
>
> >>
> > Let's assume you have a system with 48 cpus with HT on, then
> > you have 2 processor sockets, which is correct. But then you further
> > assume that topology_physical_package_id() will return 0 or 1 in this case.
>
Stephane,
On Wed, 17 Feb 2016, Stephane Eranian wrote:
Please trim your replies.
> On Wed, Feb 17, 2016 at 5:47 AM, Thomas Gleixner wrote:
> > + size = topology_max_packages() * sizeof(struct intel_uncore_box *);
> >
> Let's assume you have a system with 48 cpus with HT on, then
> you ha
Stephane Eranian writes:
>>
> Let's assume you have a system with 48 cpus with HT on, then
> you have 2 processor sockets, which is correct. But then you further
> assume that topology_physical_package_id() will return 0 or 1 in this case.
> In other words, that physical id are always assigned
On Wed, Feb 17, 2016 at 5:47 AM, Thomas Gleixner wrote:
> uncore is a per package facility, but the code tries to mimick a per cpu
> facility with completely convoluted constructs.
>
> Simplify the whole machinery by tracking per package information. While at it,
> avoid the kfree/alloc dance when
uncore is a per package facility, but the code tries to mimick a per cpu
facility with completely convoluted constructs.
Simplify the whole machinery by tracking per package information. While at it,
avoid the kfree/alloc dance when a cpu goes offline and online again. There is
no point in freeing
15 matches
Mail list logo
