On Thu, Jun 23, 2011 at 10:42:29PM +0200, Rafael J. Wysocki wrote: > On Thursday, June 23, 2011, Jesse Barnes wrote: > > On Tue, 21 Jun 2011 17:48:16 -0700 > > Ram Pai <linuxram@xxxxxxxxxx> wrote: > > > I assume majority of the platforms will have enough resources to satisfy all > > > the resource requests, and their BIOS would have done a decent job. > > > > > > Even if the BIOS has not done a decent job, and there are enough resources > > > available we should not see a regression. > > > > > > The only platforms that would expose a regression is when resources are under > > > contention and the BIOS has assigned enough resource to the cardbus bridge but > > > not to some other device. It will be hard to find such a platform, but I am > > > sure there is one out somewhere there. > > > > > > I am sure we will see; some day, reports of regression because that platform > > > would have the exact right characteristics to expose the issue. But then that > > > platform is a highly constrained platform in the first place. Its debatable if > > > that should be characterised as a regression, or a platform that was riding on > > > good luck till now. > > > > > > Even Oliver's platform is a highly constrained platform, and we probably can > > > treat his platform as 'riding on good luck till now'. > > > > > > We won't be able to satisfy all the platforms with resource constraints. I > > > think our probable choice is to select a solution that breaks least number of > > > platforms and special case those broken platforms through kernel command line > > > parameters. > > > > Another option is to hide the new allocation behavior behind a kernel > > parameter. I know Bjorn has opposed this in the past because really > > this sort of thing should "just work". But so far it hasn't, and we've > > had to revert both Bjorn's resource tracking changes as well as the > > re-allocation code. > > > > Hiding it behind a boot option would at least let us improve things > > over time and potentially switch over to new resource code in the > > future... > > > > Thoughts? > > Do I understand correctly that at the moment we have two set of systems, > one of which works with the new code and doesn't work with the old code > and the other one conversely? Here is the current state: (a) As of 2.6.39, for platforms whose BIOS have not allocated enough resources to its devices, those devices will **continue to not work**. An example of such a platform is the one whose BIOS has not allocated enough resources to SRIOV BARs. (b) With Yinghai's patch the commit "PCI: update bridge resources to get more big ranges when allocating space (again)" http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=da7822e5ad71ec9b745b412639f1e5e0ba795a20 Most of the platforms that were not working in (a) will start working, but will break a few platforms, that have resource constraints and whose BIOS has not allocated enough resources to some of its devices. Oliver's and Ben Hutching's platform are two of the known platforms; as of now. (c) with my patch all the above platforms will start working. But the 4th patch in the series raises a genuine concern that it might break resource-constrained platforms with cardbus bridges. The question is which one of these is a lesser-evil :) Personally I think we should merge all the patches except the 4th patch, and support Oliver's platform through kernel command line parameter. And I think we should revert Yinghai's patch for now and merge it with all other patches in the 3.0.1 timeframe after thorough testing. RP -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
