public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	Dave Airlie <airlied@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Gary Hade <garyhade@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: regression fixed by using pci=rom
Date: Fri, 9 May 2008 08:44:03 +0200	[thread overview]
Message-ID: <20080509064402.GA15754@elte.hu> (raw)
In-Reply-To: <alpine.LFD.1.10.0805081842030.2940@woody.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 8 May 2008, Jesse Barnes wrote:
> > 
> > Hm, yeah in many cases we definitely *do* want to try to get the 
> > expansion ROM space allocated.  But maybe it should be a lower 
> > priority than other BARs...  Gary?
> 
> The thing is, a lot of these things have been done this way because 
> not doing them that way breaks.
> 
> We want to allocate expansion ROM space - even if we don't enable it - 
> because not doing so will screw up bus sizing etc, and can make it 
> impossible to allocate later.
> 
> In general, changing PCI allocation strategy is really _really_ 
> dangerous, even when it is "right", because it tends to expose a lot 
> of issues where something worked just because it was perhaps 
> indirectly causing a layout that worked.

i tend to believe that the best strategy would be to generally do what 
other OSs do for PCI BAR sizing and PCI resource setup [on desktop 
systems that would be Windows in particular] - and i believe there are 
still a number of gratuitous-looking differences in our code that seem 
unnecessary. Especially on the myriads of desktop systems Windows is 
what gets tested primarily, and by deviating from that legacy layout we 
just set up ourselves for unnecessary failures.

To Linux the primary interest is in devices not failing due to 
unexpected layout and them not overlapping any magic areas - good 
resource compression is something that larger systems can opt-in into 
anyway if it's really needed. In that sense this commit that came 
through us failed that strict benchmark :-/

> So the reason I immediately reverted this is that it was simply 
> totally wrong. If somebody cares about multi-node systems, the onus of 
> making those work should be on *that*, not on old systems that already 
> work.
> 
> Ingo, Thomas: I would _seriously_ suggest that you don't consider the 
> x86 PCI setup code to be "x86" code. Because it isn't. Not in that 
> sense. Just don't take patches to it.

yeah, we stopped doing that in this window (the commits you got form us 
in this window were all leftovers and acked by Jesse) - and we've 
already bounced over all PCI-looking patches to Jesse and asked Jesse 
about all PCI affecting pulls as well in this window. Even this window's 
leftovers we made separate topics and sent separate pull requests for 
them (all tested and acked by Jesse) because it's not really arch/x86 
and PCI commits just need to be considered separately from all other 
changes.

	Ingo

  parent reply	other threads:[~2008-05-09  6:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-08 23:54 regression fixed by using pci=rom Dave Airlie
2008-05-09  0:17 ` Jesse Barnes
2008-05-09  1:46   ` Linus Torvalds
2008-05-09  6:29     ` Jesse Barnes
2008-05-09 16:05       ` Gary Hade
2008-05-09  6:44     ` Ingo Molnar [this message]
2008-05-09 16:45       ` Gary Hade
2008-05-09 17:26         ` Linus Torvalds
2008-05-09 18:54           ` Gary Hade
2008-05-09  1:36 ` Linus Torvalds

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=20080509064402.GA15754@elte.hu \
    --to=mingo@elte.hu \
    --cc=airlied@gmail.com \
    --cc=garyhade@us.ibm.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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