mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrew Patterson <andrew.patterson@hp.com>
Cc: linux-pci@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	jbarnes@virtuousgeek.org,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Subject: Re: [PATCH 0/1] Recurse when searching for empty slots in resources trees
Date: Tue, 16 Jun 2009 16:05:07 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0906161556020.16802@localhost.localdomain> (raw)
In-Reply-To: <1245192703.8234.226.camel@bluto.andrew>



On Tue, 16 Jun 2009, Andrew Patterson wrote:
> 
> That is at least one problem. I initially tried reparenting this stuff.
> That is what got backed out in
> http://thread.gmane.org/gmane.linux.kernel/768526/

Well, aren't we in the exact same situation still? Ie the problem (as 
Matthew claims) is:

  'Basically it was that we came across a machine with the opposite 
   problem -- that we found a parent after we found a child (and claimed 
   the child's resources), and had no way to insert the parent's region 
   above the child's region.  Alex's machine finds the child after the 
   parent and needs to insert the child's resource inside the parent's 
   resource.'

and the problem is that anything that isn't explicitly aware of the 
topology is always going to be potentially confused about things like 
this, since it's not clear at which level you want to find or add a 
resource.

> > But you fix it by making find_resource always go as deep as it can (if I 
> > read the code correctly).
> 
> Well, just deep enough.

Ok, color me confused now. When is "as deep as it can" different from your 
"just deep enough"?

> Is there a reason that find_resources should stop at the roots immediate
> child/sibling.  It seems like a bug to me. Hence this patch.

Well, find_resource() found room for a resource. So it returns it. The 
point is, your patch returns another - equally valid one.

Now, I'm not saying that your patch is wrong, but I _am_ worried that it 
(once more) changes some random heuristic when we have two choices, and it 
just makes it choose the other choice.

We've had those kinds of situations before. The thread you point to is an 
exact case of this. My point is that I'd rather try to _avoid_ any 
ambiguous cases, and try to solve it properly at a higher PCI level, where 
the ambiguity doesn't exist any more (because we'd explicitly take the 
actual bus topology into account).

So your patch may fix a bug, but I'm pretty sure I've seen a patch from 
Ivan that should _also_ fix it, and that I would expect to do it not by 
just tweaking a fundamentally ambiguous case.

		Linus

  reply	other threads:[~2009-06-16 23:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 22:04 Andrew Patterson
2009-06-16 22:04 ` [PATCH] " Andrew Patterson
2009-06-16 22:19 ` [PATCH 0/1] " Linus Torvalds
2009-06-16 22:51   ` Andrew Patterson
2009-06-16 23:05     ` Linus Torvalds [this message]
2009-06-16 23:32       ` Linus Torvalds
2009-06-17 14:45         ` Ivan Kokshaysky
2009-06-17 16:28           ` Linus Torvalds
2009-06-16 23:38       ` Andrew Patterson
2009-06-16 23:56         ` Linus Torvalds
2009-06-17  0:19           ` Linus Torvalds
2009-06-17  1:04             ` Linus Torvalds
2009-06-17  3:19               ` Andrew Patterson
2009-06-17  4:19                 ` Linus Torvalds
2009-06-17  0:28           ` Jesse Barnes
2009-06-17 16:03             ` Alex Chiang
2009-06-17  9:13 ` Kenji Kaneshige
2009-06-17 13:43   ` Matthew Wilcox
2009-06-17 16:23     ` Linus Torvalds
2009-06-17 17:42       ` Andrew Patterson
2009-06-17 18:12         ` Linus Torvalds
2009-06-17 20:08           ` Andrew Patterson
2009-06-17 20:12             ` Linus Torvalds
2009-06-17 20:17               ` Matthew Wilcox

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=alpine.LFD.2.01.0906161556020.16802@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=andrew.patterson@hp.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.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

Powered by JetHome