Hi Sai, On 3/10/2020 6:59 PM, Sai Praneeth Prakhya wrote: > On Tue, 2020-03-10 at 15:14 -0700, Reinette Chatre wrote: >> Hi Sai, >> >> Not just specific to this patch but I think the prevalent use of global >> variables that are initialized/used or allocated/released from a variety >> of places within the code is creating traps. I seemed to have stumbled >> on a few during this review so far but it is hard to keep track of and I >> am not confident that I caught them all. Having the code be symmetrical >> (allocate and free from same area or initialize and use from same area) >> does help to avoid such complexity. > > Sure! makes sense. I will try to wrap them up in some meaningful structures to > pass around functions and will see if everything still works as expected. If > not, I will comment why a particular variable needs to be global. > >> This patch and the patch that follows are both quite large and difficult >> to keep track of all the collected changes. There seems to be >> opportunity for separating it into logical changes. Some of my comments >> may be just because I could not keep track of all that is changed at the >> same time. > > Ok.. makes sense. The main reason this patch and the next patch are large > because they do two things > 1. Remove previous CAT/CQM test case > 2. Add new CAT/CQM test cases > > Since the new test cases are not just logical extensions or fixing some bugs > in previous test cases, the patch might not be readable. I am thinking to > split this at-least like this > 1. A patch to remove CAT test case > 2. A patch to remove CQM test case > 3. Patches that just add CAT and CQM (without other changes) > > Please let me know if you think otherwise I think this patch can be split up into logical changes without breaking the tests along the way. In my original review I identified two changes that can be split out. Other things that can be split out: - have CAT test take shareable bits into account - enable measurement of cache references (addition of this new perf event attribute, hooks to get measurements, etc.) - transition CAT test to use "perf rate" measurement instead of "perf count" - etc. > >> On 3/6/2020 7:40 PM, Sai Praneeth Prakhya wrote: [SNIP] >>> -static struct perf_event_attr pea_llc_miss; >>> +static struct perf_event_attr pea_llc_miss, pea_llc_access; >>> static struct read_format rf_cqm; >>> -static int fd_lm; >>> +static int fd_lm, fd_la; >>> char llc_occup_path[1024]; >>> >>> static void initialize_perf_event_attr(void) >>> @@ -27,15 +27,30 @@ static void initialize_perf_event_attr(void) >>> pea_llc_miss.inherit = 1; >>> pea_llc_miss.exclude_guest = 1; >>> pea_llc_miss.disabled = 1; >>> + >>> + pea_llc_access.type = PERF_TYPE_HARDWARE; >>> + pea_llc_access.size = sizeof(struct perf_event_attr); >>> + pea_llc_access.read_format = PERF_FORMAT_GROUP; >>> + pea_llc_access.exclude_kernel = 1; >>> + pea_llc_access.exclude_hv = 1; >>> + pea_llc_access.exclude_idle = 1; >>> + pea_llc_access.exclude_callchain_kernel = 1; >>> + pea_llc_access.inherit = 1; >>> + pea_llc_access.exclude_guest = 1; >>> + pea_llc_access.disabled = 1; >>> + >> >> This initialization appears to duplicate the initialization done above. >> Perhaps this function could be a wrapper that calls an initialization >> function with pointer to perf_event_attr that initializes structure the >> same? > > I did think about a wrapper but since pea_llc_access and pea_llc_miss are > global variables, I thought passing them as variables might not look good (why > do we want to pass a global variable?). I will try and see if I can make these > local variables. My goal was to avoid the duplicated code to initialize them identically. It is not clear to me why you think that would not look good. Perhaps I have not thought it through correctly ... Reinette
