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 15:55:01 -0600 [thread overview]
Message-ID: <CAErSpo7d+zn-qgWKcbro7yneXRtmZQCOHi+kiGzYUTfs+aiF4g@mail.gmail.com> (raw)
In-Reply-To: <CAE9FiQWrZaBpT1fzC_-mSBfDd4AKGrdGomPxVNSU-SFPrVNvOw@mail.gmail.com>
On Fri, May 25, 2012 at 2:19 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, May 25, 2012 at 12:37 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> 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;
>
> yeah, MAX_RESOURCE is better than -1.
>
>>
>> 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;
>
> can not remove this one.
> otherwise will could allocate above 4g range to non MEM64 resource.
Yeah, I convince myself of the dumbest things sometimes. It occurred
to me while driving home that we need this, but you beat me to it :)
I think we actually have a separate bug here. On 64-bit non-x86
architectures, PCIBIOS_MAX_MEM_32 is a 64-bit -1, so the following
attempt to avoid putting a 32-bit BAR above 4G only works on x86,
where PCIBIOS_MAX_MEM_32 is 0xffffffff.
/* don't allocate too high if the pref mem doesn't support 64bit*/
if (!(res->flags & IORESOURCE_MEM_64))
max = PCIBIOS_MAX_MEM_32;
I think we should fix this with a separate patch that removes
PCIBIOS_MAX_MEM_32 altogether, replacing this use with an explicit
0xffffffff (or some other "max 32-bit value" symbol). I don't think
there's anything arch-specific about this.
So I'd like to see two patches here:
1) Avoid allocating 64-bit regions for 32-bit BARs
2) Try to allocate regions above 4GB for 64-bit BARs
> also we have
>
> include/linux/range.h:#define MAX_RESOURCE ((resource_size_t)~0)
> arch/x86/kernel/e820.c:#define MAX_RESOURCE_SIZE ((resource_size_t)-1)
>
> we should merge them later?
I would support that.
Bjorn
next prev parent reply other threads:[~2012-05-25 21:55 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
2012-05-25 20:18 ` H. Peter Anvin
2012-05-25 20:19 ` Yinghai Lu
2012-05-25 21:55 ` Bjorn Helgaas [this message]
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=CAErSpo7d+zn-qgWKcbro7yneXRtmZQCOHi+kiGzYUTfs+aiF4g@mail.gmail.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).