From: Bjorn Helgaas <bhelgaas@google.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Steven Newbury <steve@snewbury.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first
Date: Thu, 24 May 2012 22:36:51 -0600 [thread overview]
Message-ID: <20120525043651.GA1391@google.com> (raw)
In-Reply-To: <CAE9FiQX=ECg5BmKm7B2ua_rZ6bOsceeHNsfFQRWBbNZx+8sBfw@mail.gmail.com>
On Wed, May 23, 2012 at 11:40:46AM -0700, Yinghai Lu wrote:
> On Wed, May 23, 2012 at 10:30 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Wed, May 23, 2012 at 8:57 AM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> >> On Tue, May 22, 2012 at 11:34 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> >>> and will fall back to below 4g if it can not find any above 4g.
> >>
> >> Has this been tested on 32-bit machines without PAE? There might be
> >> things that just happen to work because their allocations were always
> >> done bottom-up.
> >
> > Good point. that problem should be addressed at first before this patch.
>
> Just checked code for 32bit machines without PAE.
>
> when X86_PAE is not set, phys_addr_t aka resource_size_t will be 32bit.
> so in drivers/pci/bus.c::pci_bus_alloc_resource_fit()
> will have bottom to 0.
> resource_size_t bottom = PCIBIOS_MAX_MEM_32 + 1ULL;
> also in arch/x86/kernel/setup.c::setup_arch()
> iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
> will have iomem_resource.end to 0xffffffff
>
> when X86_PAE is set, but CPU does not support PAE.
> phys_addr_t aka resource_size_t will be 32bit.
I think you meant phys_addr_t and resource_size_t will be *64* bit
when X86_PAE is set. Obvious to you, but quite confusing to non-x86
experts like me :)
> so in drivers/pci/bus.c::pci_bus_alloc_resource_fit()
> will have bottom to 4g.
> resource_size_t bottom = PCIBIOS_MAX_MEM_32 + 1ULL;
> but
> in arch/x86/kernel/setup.c::setup_arch()
> iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
> will have iomem_resource.end to 0xffffffff, because x86_phys_bits is 32 when PAE
> is not detected in arch/x86/kernel/cpu/common.c::get_cpu_cap.
> that mean first try will fail, so it will go to second try with bottom to 0.
>
> so both case are safe with this patch.
I don't really like the dependency on PCIBIOS_MAX_MEM_32 + 1ULL
overflowing to zero -- that means the reader has to know what the
value of PCIBIOS_MAX_MEM_32 is, and things would break in non-obvious
ways if we changed it.
What do you think of a patch like the following? It makes it
explicit that we can only allocate space the CPU can address.
commit feded2ae21d6160292726ccd5128080d42395be4
Author: Bjorn Helgaas <bhelgaas@google.com>
Date: Thu May 24 22:15:26 2012 -0600
PCI: try to allocate 64-bit resources above 4GB
If we have a 64-bit resource, try to allocate it above 4GB first. If that
fails, either because there's no space or the CPU can't address space above
4GB (iomem_resource.end is the highest address the CPU supports), we'll
fall back to allocating space below 4GB.
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 4ce5ef2..2c56693 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -121,14 +121,18 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
{
int i, ret = -ENOMEM;
struct resource *r;
- resource_size_t max = -1;
+ resource_size_t start = 0;
+ resource_size_t end = PCIBIOS_MAX_MEM_32;
type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
- /* don't allocate too high if the pref mem doesn't support 64bit*/
- if (!(res->flags & IORESOURCE_MEM_64))
- max = PCIBIOS_MAX_MEM_32;
+ /* If this is a 64-bit resource, prefer space above 4GB */
+ if (res->flags & IORESOURCE_MEM_64) {
+ start = PCIBIOS_MAX_MEM_32 + 1ULL;
+ end = iomem_resource.end;
+ }
+again:
pci_bus_for_each_resource(bus, r, i) {
if (!r)
continue;
@@ -145,12 +149,18 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
/* Ok, try it out.. */
ret = allocate_resource(r, res, size,
- r->start ? : min,
- max, align,
+ max(start, r->start ? : min),
+ end, align,
alignf, alignf_data);
if (ret == 0)
- break;
+ return 0;
}
+
+ if (start != 0) {
+ start = 0;
+ goto again;
+ }
+
return ret;
}
next prev parent reply other threads:[~2012-05-25 4:36 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-23 6:34 [PATCH 00/11] PCI: resource allocation related Yinghai Lu
2012-05-23 6:34 ` [PATCH 01/11] PCI: Should add children device res to fail list Yinghai Lu
2012-05-23 6:34 ` [PATCH 02/11] PCI: Try to allocate mem64 above 4G at first Yinghai Lu
2012-05-23 15:57 ` Linus Torvalds
2012-05-23 17:30 ` Yinghai Lu
2012-05-23 18:40 ` Yinghai Lu
2012-05-25 4:36 ` Bjorn Helgaas [this message]
2012-05-25 17:53 ` Yinghai Lu
2012-05-25 18:39 ` Yinghai Lu
2012-05-25 19:37 ` Bjorn Helgaas
2012-05-25 20:18 ` H. Peter Anvin
2012-05-25 20:19 ` Yinghai Lu
2012-05-25 21:55 ` Bjorn Helgaas
2012-05-25 21:58 ` H. Peter Anvin
2012-05-25 22:14 ` Bjorn Helgaas
2012-05-25 23:10 ` Yinghai Lu
2012-05-26 0:12 ` Bjorn Helgaas
2012-05-26 15:01 ` Bjorn Helgaas
2012-05-29 17:56 ` Yinghai Lu
2012-05-29 17:55 ` Yinghai Lu
2012-05-29 17:57 ` H. Peter Anvin
2012-05-29 18:17 ` Yinghai Lu
2012-05-29 19:03 ` H. Peter Anvin
2012-05-29 20:46 ` Yinghai Lu
2012-05-29 20:50 ` H. Peter Anvin
2012-06-01 23:30 ` Yinghai Lu
2012-06-04 1:05 ` Bjorn Helgaas
2012-06-05 2:37 ` Yinghai Lu
2012-06-05 4:50 ` Bjorn Helgaas
2012-06-05 5:04 ` Yinghai Lu
2012-06-06 9:44 ` Steven Newbury
2012-06-06 16:18 ` Bjorn Helgaas
[not found] ` <CAGLnvc_ejMWiiubVMo7DLz5ZVn1iMbf67FB4H7crRCCTRRqt2A@mail.gmail.com>
2012-07-04 3:00 ` joeyli
2012-05-29 20:53 ` David Miller
2012-05-29 19:23 ` Bjorn Helgaas
2012-05-29 20:40 ` Yinghai Lu
2012-05-29 23:24 ` Bjorn Helgaas
2012-05-29 23:27 ` Bjorn Helgaas
2012-05-29 23:33 ` Yinghai Lu
2012-05-29 23:47 ` Bjorn Helgaas
2012-05-30 7:40 ` Steven Newbury
2012-05-30 16:27 ` Bjorn Helgaas
2012-05-30 16:30 ` H. Peter Anvin
2012-05-30 16:33 ` Linus Torvalds
2012-05-23 6:34 ` [PATCH 03/11] intel-gtt: Read 64bit for gmar_bus_addr Yinghai Lu
2012-05-23 7:21 ` Dave Airlie
2012-05-23 7:44 ` Daniel Vetter
2012-05-23 6:34 ` [PATCH 04/11] PCI: Make sure assign same align with large size resource at first Yinghai Lu
2012-05-23 6:34 ` [PATCH 05/11] resources: Split out __allocate_resource() Yinghai Lu
2012-05-23 6:34 ` [PATCH 06/11] resource: make find_resource could return just fit resource Yinghai Lu
2012-05-23 6:34 ` [PATCH 07/11] PCI: Don't allocate small resource in big empty space Yinghai Lu
2012-05-23 6:34 ` [PATCH 08/11] resource: only return range with needed align Yinghai Lu
2012-05-23 6:34 ` [PATCH 09/11] PCI: Add is_pci_iov_resource_idx() Yinghai Lu
2012-05-23 6:34 ` [PATCH 10/11] PCI: Sort unassigned resources with correct alignment Yinghai Lu
2012-05-23 6:34 ` [PATCH 11/11] PCI: Treat ROM resource as optional during assigning 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=20120525043651.GA1391@google.com \
--to=bhelgaas@google.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=steve@snewbury.org.uk \
--cc=torvalds@linux-foundation.org \
--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).