From: Bjorn Helgaas <bhelgaas@google.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: David Miller <davem@davemloft.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Wei Yang <weiyang@linux.vnet.ibm.com>, TJ <linux@iam.tj>,
Yijing Wang <wangyijing@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/51] PCI: Optimize bus align/size calculation during sizing
Date: Mon, 17 Aug 2015 18:49:31 -0500 [thread overview]
Message-ID: <20150817234931.GP26431@google.com> (raw)
In-Reply-To: <1438039809-24957-5-git-send-email-yinghai@kernel.org>
On Mon, Jul 27, 2015 at 04:29:22PM -0700, Yinghai Lu wrote:
> Current code try to get align as small as possible and use that to
> align final size. But it does not handle resource that size is bigger
> than align in optimal way, kernel only use max align for them.
>
> For example:
> when we have resources with align/size: 1M/2M, 512M/512M,
> bus resource min_align/size0 will be 512M/1024M,
> but optimal value should be 256M/768M.
I want to understand what makes 256M/768M "optimal."
This is basically a bin packing problem, and I'd like to have an
explicit statement of the constraints and the goal. Right now the
goal is fuzzy and the code seems ad hoc.
Here are the possibilities I can see. The placement notes are the
offsets into the allocated space:
align size 512M placement 2M placement unused
1024M 514M [0-512] [512-514] [514-1024]
512M 514M [0-512] [512-514] none
256M 768M [256-768] [254-256] [0-254]
128M 896M [384-896] [382-384] [0-382]
Obviously, we would never choose 1024M/514M or any larger alignment:
it requires no more space than 512M/514M, but it fails in some cases
where 512M/514M would succeed.
Also obviously, we would never choose 128M/896M or a smaller
alignment: if we could get that, we could also get 256M/768M and it
would consume less space.
But it's not quite so obvious how to choose between 512M/514M and
256M/768M. The former (if we can get it) consumes much less space.
The latter requires less alignment but wastes a lot of space.
> For following cases that we have resource size that is bigger
> than resource alignment:
> 1. SRIOV bar.
> 2. PCI bridges with several bridges or devices as children.
This doesn't have anything to do with how many children a bridge has,
does it? As long as there are two or more BARs (1MB or larger) below
a bridge, we'll have the situation where the bridge window has to
contain both BARs but only needs to be aligned for (at most) the
larger one.
> We can keep on trying to allocate children devices resources under range
> [half_align, half_align + aligned_size).
> If sucesses, we can use that half_align as new min_align.
>
> After this patch, we get:
> align/size: 1M/2M, 2M/4M, 4M/8M, 8M/16M
> new min_align/min_size: 4M/32M, and old is 8M/32M
>
> align/size: 1M/2M, 2M/4M, 4M/8M
> new min_align/min_size: 2M/14M, and old is 4M/16M
>
> align/size: 1M/2M, 512M/512M
> new min_align/min_size: 256M/768M, and old is 512M/1024M
>
> The real result from one system with one pcie card that has
> four functions that support sriov:
> align/size:
> 00800000/00800000
> 00800000/00800000
> 00800000/00800000
> 00800000/00800000
> 00010000/00200000
> 00010000/00200000
> 00010000/00200000
> 00010000/00200000
> 00008000/00008000
> 00008000/00008000
> 00008000/00008000
> 00008000/00008000
> 00004000/00080000
> 00004000/00080000
> 00004000/00080000
> 00004000/00080000
> old min_align/min_size: 00400000/02c00000
> min_align/min_size: 00100000/02b00000
I don't know if this example is essential, but if it is, it needs a
little more interpretation. I assume the BARs above where
"align < size" are for SR-IOV, where size include multiple VFs.
In any case, please connect the dots from the raw data to the
conclusion.
> So align will be 1M instead of 4M.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
> Reported-by: TJ <linux@iam.tj>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> ---
> drivers/pci/setup-bus.c | 195 ++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 157 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 27cb0f0..ecdf011 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -30,6 +30,34 @@
>
> unsigned int pci_flags;
>
> +static inline bool is_before(resource_size_t align1, resource_size_t size1,
> + resource_size_t align2, resource_size_t size2)
Can this take two struct resource pointers instead of four numbers? I
haven't looked at all the callers, so maybe there's a caller that
doesn't have a struct resource.
> +{
> + resource_size_t size1_left, size2_left;
> +
> + /* big align is before small align */
> + if (align1 > align2)
> + return true;
> +
> + /*
> + * for same align:
> + * aligned is before not aligned
> + * for not aligned, big remainder is before small remainder
> + */
> + if (align1 == align2) {
> + size1_left = size1 & (align1 - 1);
> + if (!size1_left)
> + size1_left = align1;
> + size2_left = size2 & (align2 - 1);
> + if (!size2_left)
> + size2_left = align2;
> + if (size1_left > size2_left)
> + return true;
> + }
> +
> + return false;
> +}
next prev parent reply other threads:[~2015-08-17 23:49 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 23:29 [PATCH v3 00/51] PCI: Resource allocation cleanup for v4.3 Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 01/51] PCI: Cleanup res_to_dev_res() printout for addon resources Yinghai Lu
2015-08-17 22:50 ` Bjorn Helgaas
2015-08-18 21:19 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 02/51] PCI: Reuse res_to_dev_res in reassign_resources_sorted Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 03/51] PCI: Use correct align for optional only resources during sorting Yinghai Lu
2015-08-17 23:00 ` Bjorn Helgaas
2015-08-18 19:01 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 04/51] PCI: Optimize bus align/size calculation during sizing Yinghai Lu
2015-08-17 23:49 ` Bjorn Helgaas [this message]
2015-08-18 20:29 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 05/51] PCI: Optimize bus align/size calculation for optional " Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 06/51] PCI: Don't add too much optional size for hotplug bridge mmio Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 07/51] PCI: Reorder resources list for must/optional resources Yinghai Lu
2015-08-17 23:52 ` Bjorn Helgaas
2015-08-18 20:58 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 08/51] PCI: Remove duplicated code for resource sorting Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 09/51] PCI: Rename pdev_sort_resources to pdev_check_resources Yinghai Lu
2015-08-17 23:53 ` Bjorn Helgaas
2015-08-18 21:36 ` Yinghai Lu
2015-08-18 21:45 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 10/51] PCI: Treat ROM resource as optional during realloc Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 11/51] PCI: Add debug printout during releasing partial assigned resources Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 12/51] PCI: Simplify res reference using in __assign_resourcs_sorted Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 13/51] PCI: Separate realloc list checking after allocation Yinghai Lu
2015-08-17 23:54 ` Bjorn Helgaas
2015-08-18 21:58 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 14/51] PCI: Add __add_to_list() Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 15/51] PCI: Cache window alignment value Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 16/51] PCI: Check if resource is allocated before pci_assign Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 17/51] PCI: Separate out save_resources/restore_resource Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 18/51] PCI: Move comment to pci_need_to_release() Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 19/51] PCI: Separate must+optional assigning to another function Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 20/51] PCI: Skip must+optional if there is no optional addon Yinghai Lu
2015-08-17 23:56 ` Bjorn Helgaas
2015-08-18 22:39 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 21/51] PCI: Move saved required resource list out of must+optional assigning Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 22/51] PCI: Add alt_size allocation support Yinghai Lu
2015-08-18 0:03 ` Bjorn Helgaas
2015-08-19 5:28 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 23/51] PCI: Add support for more than two alt_size under same bridge Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 24/51] PCI: Better support for two alt_size Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 25/51] PCI: Fix size calculation with old_size on rescan path Yinghai Lu
2015-08-18 4:09 ` Bjorn Helgaas
2015-08-19 6:25 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 26/51] PCI: Don't add too much optional size for hotplug bridge io Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 27/51] PCI: Move ISA ioport align out of calculate_iosize Yinghai Lu
2015-08-18 4:11 ` Bjorn Helgaas
2015-08-19 6:32 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 28/51] PCI: Unifiy calculate_size for io port and mmio Yinghai Lu
2015-08-18 4:13 ` Bjorn Helgaas
2015-08-19 6:37 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 29/51] PCI: Allow optional only io resource must size to be 0 Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 30/51] PCI: Unify skip_ioresource_align() Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 31/51] PCI: Kill macro checking for bus io port sizing Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 32/51] resources: Split out __allocate_resource() Yinghai Lu
2015-08-18 4:14 ` Bjorn Helgaas
2015-08-19 6:58 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 33/51] resources: Make allocate_resource return just fit resource Yinghai Lu
2015-08-18 4:21 ` Bjorn Helgaas
2015-08-19 7:22 ` Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 34/51] PCI: Check pref compatible bit for mem64 resource of pcie device Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 35/51] PCI: Only treat non-pef mmio64 as pref if all bridges has MEM_64 Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 36/51] PCI: Add has_mem64 for host_bridge Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 37/51] PCI: Only treat non-pef mmio64 as pref if host-bridge has_mem64 Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 38/51] PCI: Restore pref mmio allocation logic for hostbridge without mmio64 Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 39/51] sparc/PCI: Add mem64 resource parsing for root bus Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 40/51] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in of parsing Yinghai Lu
2015-07-27 23:29 ` [PATCH v3 41/51] powerpc/PCI: " Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 42/51] of/PCI: Add IORESOURCE_MEM_64 for 64-bit resource Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 43/51] PCI: Treat optional as must in first try for bridge rescan Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 44/51] PCI: Get new realloc size for bridge for last try Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 45/51] PCI: Don't release sibiling bridge resources during hotplug Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 46/51] PCI: Don't release fixed resource for realloc Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 47/51] PCI: Claim fixed resource during remove/rescan path Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 48/51] PCI: Set resource to FIXED for lsi devices Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 49/51] PCI, x86: Add pci=assign_pref_bars to re-allocate pref bars Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 50/51] PCI: Introduce resource_disabled() Yinghai Lu
2015-07-27 23:30 ` [PATCH v3 51/51] PCI: Don't set flags to 0 when assign resource fail Yinghai Lu
2015-08-17 22:48 ` [PATCH v3 00/51] PCI: Resource allocation cleanup for v4.3 Bjorn Helgaas
2015-08-18 18:43 ` Yinghai Lu
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=20150817234931.GP26431@google.com \
--to=bhelgaas@google.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@iam.tj \
--cc=wangyijing@huawei.com \
--cc=weiyang@linux.vnet.ibm.com \
--cc=yinghai@kernel.org \
/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).