All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 25 May 2012 13:37:16 -0600	[thread overview]
Message-ID: <20120525193716.GA8817@google.com> (raw)
In-Reply-To: <CAE9FiQW0rm2_sKdSCWs3TfatJB9yHwvmvt9_vBYMtOq_YBbmfw@mail.gmail.com>

On Fri, May 25, 2012 at 11:39:26AM -0700, Yinghai Lu wrote:
> On Fri, May 25, 2012 at 10:53 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> >> 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.
> >>
> 
> please check if attached one is more clear.
> 
> make max and bottom is only related to _MEM and not default one.
> 
> -       if (!(res->flags & IORESOURCE_MEM_64))
> -               max = PCIBIOS_MAX_MEM_32;
> +       if (res->flags & IORESOURCE_MEM) {
> +               if (!(res->flags & IORESOURCE_MEM_64))
> +                       max = PCIBIOS_MAX_MEM_32;
> +               else if (PCIBIOS_MAX_MEM_32 != -1)
> +                       bottom = (resource_size_t)(1ULL<<32);
> +       }
> 
> will still not affect to other arches.

That's goofy.  You're proposing to make only x86_64 and x86-PAE try to put
64-bit BARs above 4GB.  Why should this be specific to x86?  I acknowledge
that there's risk in doing this, but if it's a good idea for x86_64, it
should also be a good idea for other 64-bit architectures.

And testing for "is this x86_32 without PAE?" with
"PCIBIOS_MAX_MEM_32 == -1" is just plain obtuse and hides an
important bit of arch-specific behavior.

Tangential question about allocate_resource():  Is its "max" argument
really necessary?  We'll obviously only allocate from inside the root
resource, so "max" is just a way to artificially avoid the end of
that resource.  Is there really a case where that's required?

"min" makes sense because in a case like this, it's valid to allocate from
anywhere in the root resource, but we want to try to allocate from the >4GB
part first, then fall back to allocating from the whole resource.  I'm not
sure there's a corresponding case for "max."

Getting back to this patch, I don't think we should need to adjust "max" at
all.  For example, this:

commit cb1c8e46244cfd84a1a2fe91be860a74c1cf4e25
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu May 24 22:15:26 2012 -0600

    PCI: try to allocate 64-bit mem resources above 4GB
    
    If we have a 64-bit mem resource, try to allocate it above 4GB first.  If
    that fails, we'll fall back to allocating space below 4GB.

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 4ce5ef2..075e5b1 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -121,14 +121,16 @@ 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 = MAX_RESOURCE;
 
 	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 mem resource, try above 4GB first */
+	if (res->flags & IORESOURCE_MEM_64)
+		start = (resource_size_t) (1ULL << 32);
 
+again:
 	pci_bus_for_each_resource(bus, r, i) {
 		if (!r)
 			continue;
@@ -145,12 +147,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;
 }
 

  reply	other threads:[~2012-05-25 19:37 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
2012-05-25 17:53           ` Yinghai Lu
2012-05-25 18:39             ` Yinghai Lu
2012-05-25 19:37               ` Bjorn Helgaas [this message]
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=20120525193716.GA8817@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.