On Wed, Apr 9, 2014 at 1:52 AM, Guo Chao <yan@xxxxxxxxxxxxxxxxxx> wrote: >> OK, then I'm back to square one, and I need an explanation of why we >> want to merge this patch. >> >> I think the patch conserves 32-bit address space by putting more >> things above 4G than we used to. But this comes at the cost of using >> non-prefetchable windows in some cases where we used to use >> prefetchable ones. >> >> Somebody has to explain why we want to do this and why the benefit of >> conserving the 32-bit space is more important losing the >> prefetchability. > > I want to make sure we are talking about this patch: > PCI: Try best to allocate pref mmio 64bit above 4g > http://patchwork.ozlabs.org/patch/328067/ > > instead of this one: > PCI: Try to allocate mem64 above 4G at first > http://patchwork.ozlabs.org/patch/303197/ Yes, I'm talking about http://patchwork.ozlabs.org/patch/328067; if you look at patchwork, the second one (303197) is marked "superseded." > This patch does not intend to conserve 32-bit space at all. It makes > better use of prefetchable window. > > The problem with the old code is: when both 32-bit and 64-bit prefetchable > BARs present, it's in favor of 32-bit one to use prefetchable window. > This window is then not supposed to get 4G-above address, and this > 32-bit-address-only property would propagates upwards until reaching root > bridge. In later assignment phase, 4G-above space is never touched. This > is just caused by a single 32-bit prefetchable BAR (say a ROM BAR). > > This patch helps by making better decision: > > * Keep the old behaviour if only 32-bit or 64-bit prefetchable > BARs present > > * If both of them present, put 64-bit ones to prefetchable window, > 32-bit ones to non-prefetchable window I thought the patch was supposed to change the way we allocate bridge windows. But you are talking about the way we assign 32- and 64-bit device resources, i.e., changing the way we decide whether to put them in prefetchable or non-prefetchable windows. > So 4G-above space can be properly used. > > Why does enabling 64-bit space matter? > > * 32-bit space is just too small. If larger-than-4G BAR sounds > unrealistic (we do have such devices), there is still a chance that > total MMIO size under a domain is too large, especially when SR-IOV > enabled (we met this situation). Please give more details about the problem you saw. A complete dmesg log showing a boot failure or a device that doesn't work, and another log with this patch applied, showing things working as desired, would go a long ways toward clarifying this. This sounds like a specific case that will be fixed by the patch, and if you give more details, maybe I can figure out what's going on. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
