Hi Aubrey, Li, Aubrey wrote: > I just want to update the current working status of the c-state part of PAD. > > I think before put back into ON, we have to finish the following things: > > 1) cmt_balance() should be aware of the requirement of the current system, > not messed power and perf up. That is, if perf is prefered, power related pg > should be ignored. > This is done for P-state domains, but I think we still need to do this for the idle power domains.
> 2) [bug #4581] power idle group should be ahead of power active group for cmt > coalesce policy > >> I failed to understand why it is marked as a duplicate of bug 4616 >> 4616 should ensure that if a CPU is selected from a given domain (for example, the active domain T0-T3), that the shallow sleeping CPUs are preferred. This is why I closed it as a dup of 4581 as a dup of 4616. I don't think we can fix the problem described in 4581 (which I agree is a legitimate problem) by promoting the idle groups above the active groups as is suggested there, since the current code assumes that a given PGs parent has the same or greater number of CPUs...and promoting the core level groups above the socket level group would make this not true. > 3) [bug #4616] cmt_balance schedules thread on any idle CPU instead of > shallow idle CPUs > > 4) [bug #5444] the system should not enter deep cstate at all when under > heavy load. > > 5) Per current implementation > ===================================================== > pg = GROUP_ACCESS(cmt_pgs, level); > > siblings = pg->cmt_siblings; > nsiblings = GROUP_SIZE(siblings); /* self inclusive */ > if (nsiblings == 1) > continue; /* nobody to balance against */ > ===================================================== > cmt balance will ignore a pg if its siblings size = 1. I found on pad head, > power idle pg's sibling > size = 1, that means power idle pg will be ignored forever. \ > Yes, this is broken. The siblings size should be 4. > This problem is simiar as "[Bug 4015] Integer Pipeline processor group is > broken", which is > closed and move the issue to 4616. > Ok. I'll take a look and will either re-open 4616 or file a new bug.... Thanks. > Is there anything I missed? > Just a few more things come to mind... - We need a way of tuning the capacity of the domains across which the coalescence policy is implemented. Currently, the dispatcher is willing to pack all 8 threads of a NHM chip before moving on to the next socket, and we're thinking that placing 4 threads per socket (one per core) before moving to the next socket might perform better. I'm working on this.... - Need to close on the PSARC case for the cpupm keyword extensions - Need to properly deal with _PPC notifications. Thanks, -Eric > Thanks, > -Aubrey > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
