On Mon, Jan 16, 2012 at 2:29 AM, Ram Pai <linuxram@xxxxxxxxxx> wrote: >> > Its not just about 'not enough resources', it also about making the right >> > choice of 'who should get the resource if there is contention'. Only the BIOS >> > knows about it. But we trash the BIOS's allocation and don't use that >> > knowledge when it comes to making those hard choices. >> >> in extreme case, will let the user to use "pci=norealloc" to disable >> changing pci bridge resource set by BIOS. > > I know its a pathological case. But still this issue will be viewed as a > regression. I had to struggle to solve this regression in order to get your > realloc patch re-accepted. Don't know if you can successfully make a case > to by-pass the regression this time. Yes, you had introduced the optional res concept, and that is very good. but we still have some problems that my new patch set try to fix: 1. sometimes optional size is not passed to up bridge level correctly. 2. requested the expand optional does not go extra upper level. 3. requested and then expand does not work on two requested + optional, only can make one happy. because request stuck in the middle. > > One way to solve this problem is to allocate 'required' resources first, and > later aggressively try to allocate 'required+optional' resources. However > aggressively allocation of those 'required+optional' resource would require > ensuring minimal internal fragmentation. that will make case 2: do not go extra level. or we can do: We try to auto detect if we need to enable realloc. (something like sriov is enabled, but some SRIOV registers are not assigned) (or card bus are there etc) and pci=realloc become pci=realloc=off and pci=realloc=on so user can forcely turn it or off. Thanks Yinghai -- 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
