On 01/14/2013 04:55 PM, li guang wrote: >>>>>> > > >> > - /* while loop will break here if sd == NULL */ >>>> > > > I agree that this should be a major optimization. I just can't figure >>>> > > > out why the existing recursive search for an idle cpu switches to the >>>> > > > new cpu near the end and then starts a search for an idle cpu in the >>>> > > > new >>>> > > > cpu's domain. Is this to handle some exotic sched domain >>>> > > > configurations? >>>> > > > If so, they probably wouldn't work with your optimizations. >>> > > >>> > > I did not find odd configuration that asking for old logical. >>> > > >>> > > According to Documentation/scheduler/sched-domains.txt, Maybe never. >>> > > "A domain's span MUST be a superset of it child's span (this restriction >>> > > could be relaxed if the need arises), and a base domain for CPU i MUST >>> > > span at least i." etc. etc. >> > >> > The reason for my suspicion is the SD_OVERLAP flag, which has something >> > to do overlapping sched domains. I haven't looked into what it does or >> > how it works. I'm just wondering if this optimization will affect the >> > use of that flag. > seems it did, SD_OVERLAP will not work after this change, > though this flag is maybe scarcely used. > because, this optimization assume all sched-domains span > is super-set over child domain. > isn't it? Alex. >
As my understanding, overlap just said some cpu may appears in 2 or more same level sub domains. If so, this change won't miss cpus. Am I right, Peter? -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
