On Mon, Dec 08, 2014 at 04:21:34PM -0800, Yinghai Lu wrote: > On Mon, Dec 8, 2014 at 3:38 PM, Gavin Shan <gwshan@xxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Dec 08, 2014 at 02:46:00PM -0700, Bjorn Helgaas wrote: > >>Yeah, I didn't word that very clearly. I meant that after > >>5b28541552ef, that 64-bit window is wasted unless there's a 64-bit BAR > >>below it; we can't even place the window below 4GB and use it for > >>32-bit prefetchable BARs. > > > > Yes, I agree. It's why I suggested to return error from pbus_size_mem() > > to indicate the case: 64-bits prefetchable window isn't used and it's > > still available to be used by child 32-bits prefetchable BARs. Please > > take a look on the attached draft patch, which helps to explain the idea > > only. > > That would not help. The 00:01.0 on Zermond's system support hotplug. so mem > pref will be used for 64bit pref. Maybe it doesn't work as-is, but I think the idea is worth pursuing. We can tell whether there are existing children, and we can tell whether there are any 64-bit prefetchable BARs. If there is already a device below a hotplug bridge, and it has no 64-bit BARs, I think we should use the prefetchable window for that device. It seems silly to reserve the prefetchable window for a possible future hot-added device. That means we penalize the device we already know about because it can't have any prefetchable space. And we've consumed some 64-bit space that is unused. We only benefit if we hot-remove the existing device and hot-add a new device with 64-bit BARs that happen to fit inside the 2MB (DEFAULT_HOTPLUG_MEM_SIZE) we allocated for it. That seems pretty unlikely. I don't see any patches that resolve the regression (bug 85491) yet. If we don't figure something out, I'm going to have to revert 5b28541552ef. 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
