From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: akataria@vmware.com
Cc: Andi Kleen <ak@linux.intel.com>, Ingo Molnar <mingo@elte.hu>,
Len <len.brown@intel.com>, LKML <linux-kernel@vger.kernel.org>,
linux-acpi <linux-acpi@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
TJ <linux@tjworld.net>
Subject: Re: acpi based pci gap calculation - v3
Date: Wed, 23 Jul 2008 10:52:22 -0700 [thread overview]
Message-ID: <200807231052.22806.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <1216833034.6354.12.camel@alok-dev1>
On Wednesday, July 23, 2008 10:10 am Alok Kataria wrote:
> Hi Jesse,
>
> On Wed, 2008-07-23 at 09:58 -0700, Jesse Barnes wrote:
> > On Tuesday, July 22, 2008 3:52 pm Alok Kataria wrote:
> > > So the gap that we had calculated first i.e. from e820_setup_gap did
> > > contain a collision i.e. though a resource was reserved from
> > > [0xf0000000 - 0xf7ffffff] our gap calculation doesn't take that into
> > > account. My patch fixes this issue.
> > >
> > > So, IMHO this is a BUG and should be fixed. Please let me know your
> > > views.
> >
> > Yes, there's a conflict there, but on many machines it's probably a
> > harmless one. My main concerns are these:
> > 1) it changes long standing behavior and doesn't fix any real reported
> > bugs I'm aware of (feel free to point me at some)
>
> The problem that I see is with Memory Hotadd, though my BIOS exports the
> correct SRAT table and tells the OS that some regions are hot pluggable,
> PCI gap calculation ignores that info and assigns some "option ROMS" in
> hot pluggable memory region.
>
> Because of this when i try to hot add memory, the OS sees a resource
> allocation conflict and bails out. Which shouldn't have happened,
> right ?
Ah ok, so you've got a real problem here. And I don't deny that there's a
conflict that we should fix.
> > 2) it looks like it will dramatically reduce the available PCI resource
> > space on at least some platforms, and that space is already scarce
> > in our current scheme
>
> IMO, these gaps are used only for the option ROMS or hot pluggable
> devices which in itself are rare. So its not like we are reducing the
> whole available PCI resource space, but only the space that is needed by
> these optional ROMS.
> And i think its inevitable if we have to remove these conflicts with any
> other subsystem.
Actually we have other allocations. In many cases the BIOS won't assign MMIO
resources, so we do it at boot time. Most of the open PCI bugs we have today
are resource allocation failures, and not just for ROMs, so hopefully you can
understand my worry. Using all available gaps rather than just the largest
seems like the obvious first step to increasing our available space, and
would give us more leeway to avoid stomping on other reserved space.
Jesse
next prev parent reply other threads:[~2008-07-23 17:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 18:59 acpi based pci gap calculation - v3 Alok Kataria
2008-07-15 20:28 ` Jesse Barnes
2008-07-15 20:54 ` Alok Kataria
2008-07-15 22:53 ` Jesse Barnes
2008-07-15 23:07 ` Ingo Molnar
2008-07-16 5:40 ` Andi Kleen
2008-07-16 16:06 ` Jesse Barnes
2008-07-16 16:33 ` Andi Kleen
2008-07-17 0:03 ` Jesse Barnes
2008-07-17 21:31 ` Alok Kataria
[not found] ` <1216663147.26169.5.camel@alok-dev1>
[not found] ` <200807221450.52114.jbarnes@virtuousgeek.org>
2008-07-22 22:52 ` Alok Kataria
2008-07-23 7:13 ` TJ
2008-07-23 16:58 ` Jesse Barnes
2008-07-23 17:10 ` Alok Kataria
2008-07-23 17:52 ` Jesse Barnes [this message]
2008-07-23 18:02 ` Alok Kataria
2008-07-16 5:42 ` Andi Kleen
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=200807231052.22806.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=ak@linux.intel.com \
--cc=akataria@vmware.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@tjworld.net \
--cc=mingo@elte.hu \
/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