From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, benh@kernel.crashing.org,
mpe@ellerman.id.au, bhelgaas@google.com, robherring2@gmail.com,
dja@axtens.net, alistair@popple.id.au
Subject: Re: [PATCH v9 04/22] powerpc/powernv: Increase PE# capacity
Date: Fri, 6 May 2016 21:05:42 +1000 [thread overview]
Message-ID: <20160506110541.GA5016@gwshan> (raw)
In-Reply-To: <2f2282ae-c1dc-1870-4beb-d5e4e8233496@ozlabs.ru>
On Fri, May 06, 2016 at 05:17:25PM +1000, Alexey Kardashevskiy wrote:
>On 05/03/2016 11:22 PM, Gavin Shan wrote:
>>Each PHB maintains an array helping to translate 2-bytes Request
>>ID (RID) to PE# with the assumption that PE# takes one byte, meaning
>>that we can't have more than 256 PEs. However, pci_dn->pe_number
>>already had 4-bytes for the PE#.
>
>Can you possibly have more than 256 PEs? Or exactly 256? What patch in this
>series makes use of it?
>
>I probably asked but do not remember the answer :)
>
>Looks like waste of memory - you only used a small fraction of
>pe_rmap[0x10000] and now the waste is quadrupled.
>
The PE capacities on different hardware are different as below. So we're
going to support 16-bits PE number in near future. That means the element
in the array needs "unsigned short" at least and 2 pages (2 * 64KB) will
be reserved for it.
P7IOC: 127 PHB3: 256
PHB4: 65536 NPU1: 4 NPU2: 16
I agree some memory is wasted and the wasted amount depends on the PCI
topology. No memory will be wasted if 256 busses show on one particular
PHB. Less busses one PHB has, more memory will be wasted. As I explained
before, the total used memory is 4 pages (4 * 64KB). Considering the memory
capacity on PPC64 (especially PowerNV), I guess it's fine. Note that the
memory is allocated from memblock together with PHB instance.
The alternative solution (to avoid wasting memory) would be searching for
the PE number according to the input BDFN through the PE list maintained
in each PHB. Obviously, it will induce more logic and more CPU cycles will
be used. So it's a kind of trade-off. If you really want to see this, I
absolutely can do it in next revision. Another option would be to improve
it later and keep the code as what we have. Please input your thought.
>
>>
>>This extends the PE# capacity for every PHB. After that, the PE number
>>is represented by 4-bytes value. Then we can reuse IODA_INVALID_PE to
>>check the PE# in phb->pe_rmap[] is valid or not.
>
>Looks like using IODA_INVALID_PE is the only reason for this patch.
>
For now, yes. In near future, It needs to be extended to represent 16-bits
PE number for PHB4 as I explained above.
>
>>
>>Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>>Reviewed-by: Daniel Axtens <dja@axtens.net>
>>---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 6 +++++-
>> arch/powerpc/platforms/powernv/pci.h | 7 ++-----
>> 2 files changed, 7 insertions(+), 6 deletions(-)
>>
>>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>>index cbd4c0b..cf96cb5 100644
>>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>>@@ -768,7 +768,7 @@ static int pnv_ioda_deconfigure_pe(struct pnv_phb *phb, struct pnv_ioda_pe *pe)
>>
>> /* Clear the reverse map */
>> for (rid = pe->rid; rid < rid_end; rid++)
>>- phb->ioda.pe_rmap[rid] = 0;
>>+ phb->ioda.pe_rmap[rid] = IODA_INVALID_PE;
>>
>> /* Release from all parents PELT-V */
>> while (parent) {
>>@@ -3406,6 +3406,10 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
>> if (prop32)
>> phb->ioda.reserved_pe_idx = be32_to_cpup(prop32);
>>
>>+ /* Invalidate RID to PE# mapping */
>>+ for (segno = 0; segno < ARRAY_SIZE(phb->ioda.pe_rmap); segno++)
>>+ phb->ioda.pe_rmap[segno] = IODA_INVALID_PE;
>>+
>> /* Parse 64-bit MMIO range */
>> pnv_ioda_parse_m64_window(phb);
>>
>>diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
>>index 904f60b..80f5326 100644
>>--- a/arch/powerpc/platforms/powernv/pci.h
>>+++ b/arch/powerpc/platforms/powernv/pci.h
>>@@ -156,11 +156,8 @@ struct pnv_phb {
>> struct list_head pe_list;
>> struct mutex pe_list_mutex;
>>
>>- /* Reverse map of PEs, will have to extend if
>>- * we are to support more than 256 PEs, indexed
>>- * bus { bus, devfn }
>>- */
>>- unsigned char pe_rmap[0x10000];
>>+ /* Reverse map of PEs, indexed by {bus, devfn} */
>>+ unsigned int pe_rmap[0x10000];
>>
>> /* TCE cache invalidate registers (physical and
>> * remapped)
>>
>
>
>--
>Alexey
>
next prev parent reply other threads:[~2016-05-06 11:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-03 13:22 [PATCH v9 00/22] powerpc/powernv: PCI hotplug support Gavin Shan
2016-05-03 13:22 ` [PATCH v9 01/22] PCI: Add pcibios_setup_bridge() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 02/22] powerpc/pci: Override pcibios_setup_bridge() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 03/22] powerpc/powernv: Move pnv_pci_ioda_setup_opal_tce_kill() around Gavin Shan
2016-05-06 6:36 ` Alexey Kardashevskiy
2016-05-03 13:22 ` [PATCH v9 04/22] powerpc/powernv: Increase PE# capacity Gavin Shan
2016-05-06 7:17 ` Alexey Kardashevskiy
2016-05-06 11:05 ` Gavin Shan [this message]
2016-05-03 13:22 ` [PATCH v9 05/22] powerpc/powernv: Allocate PE# in reverse order Gavin Shan
2016-05-03 13:22 ` [PATCH v9 06/22] powerpc/powernv: Create PEs in pcibios_setup_bridge() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 07/22] powerpc/powernv: Setup PE for root bus Gavin Shan
2016-05-03 13:22 ` [PATCH v9 08/22] powerpc/powernv: Extend PCI bridge resources Gavin Shan
2016-05-03 13:22 ` [PATCH v9 09/22] powerpc/powernv: Make pnv_ioda_deconfigure_pe() visible Gavin Shan
2016-05-03 13:22 ` [PATCH v9 10/22] powerpc/powernv: Dynamically release PE Gavin Shan
2016-05-03 13:22 ` [PATCH v9 11/22] powerpc/pci: Update bridge windows on PCI plug Gavin Shan
2016-05-03 13:22 ` [PATCH v9 12/22] powerpc/pci: Delay populating pdn Gavin Shan
2016-05-03 13:22 ` [PATCH v9 13/22] powerpc/powernv: Support PCI slot ID Gavin Shan
2016-05-03 13:22 ` [PATCH v9 14/22] powerpc/powernv: Use PCI slot reset infrastructure Gavin Shan
2016-05-03 13:22 ` [PATCH v9 15/22] powerpc/powernv: Functions to get/set PCI slot state Gavin Shan
2016-05-11 3:28 ` Alistair Popple
2016-05-03 13:22 ` [PATCH v9 16/22] drivers/of: Split unflatten_dt_node() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 17/22] drivers/of: Avoid recursively calling unflatten_dt_node() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 18/22] drivers/of: Rename unflatten_dt_node() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 19/22] drivers/of: Specify parent node in of_fdt_unflatten_tree() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 20/22] drivers/of: Return allocated memory from of_fdt_unflatten_tree() Gavin Shan
2016-05-03 13:22 ` [PATCH v9 21/22] drivers/of: Export of_detach_node() Gavin Shan
2016-05-04 13:36 ` Gavin Shan
2016-05-05 19:42 ` Rob Herring
2016-05-06 0:40 ` Gavin Shan
2016-05-03 13:22 ` [PATCH v9 22/22] PCI/hotplug: PowerPC PowerNV PCI hotplug driver Gavin Shan
2016-05-05 17:04 ` Rob Herring
2016-05-06 0:28 ` Gavin Shan
2016-05-06 13:12 ` Rob Herring
2016-05-08 23:51 ` Gavin Shan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160506110541.GA5016@gwshan \
--to=gwshan@linux.vnet.ibm.com \
--cc=aik@ozlabs.ru \
--cc=alistair@popple.id.au \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dja@axtens.net \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=robherring2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).