<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 6:43 PM Jan Stancek <<a href="mailto:jstancek@redhat.com">jstancek@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> >And the worth to say, the random directory name for same cgroup<br>
>> >mounting is also on purpose, though we mount same(i.e memory)<br>
>> >cgroup in two places it still belongs to the one hierarchy, and create<br>
>> >the same name of the new directory will be hit an error in EEXIST.<br>
>> ><br>
>> >static void tst_cgroup_set_path(const char *cgroup_dir)<br>
>> >{<br>
>> >    ...<br>
>> >    sprintf(tst_cgroup_mnt_path, "%s", cgroup_dir);<br>
>> >    sprintf(tst_cgroup_new_path, "%s/ltp_%d", cgroup_dir, rand());<br>
>><br>
>> I see why you are tracking this in list, but this exchange of state through<br>
>> global variables does seem bit unclear.<br>
>><br>
><br>
>Yes, that's a compromise to support more usage of the APIs.<br>
<br>
I don't get why global variables are necessary.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The only reason to export them as global variables is to make the legacy</div><div class="gmail_default" style="font-size:small">read/write_cpuse_files() happy. So that I said it is a compromise.</div><br></div><div><div class="gmail_default" style="font-size:small">$ git grep tst_cgroup_new_path</div>cpuset/cpuset01.c:      write_cpuset_files(tst_cgroup_new_path, "cpus", buf);<br>cpuset/cpuset01.c:      write_cpuset_files(tst_cgroup_new_path, "mems", mems);<br>cpuset/cpuset01.c:      write_cpuset_files(tst_cgroup_new_path, "mems", buf);<br>cpuset/cpuset01.c:      write_cpuset_files(tst_cgroup_new_path, "mems", buf);<br>lib/mem.c:      write_cpuset_files(tst_cgroup_new_path, "mems", buf);<br>lib/mem.c:              write_cpuset_files(tst_cgroup_new_path, "cpus", cpus);<br>lib/mem.c:              write_cpuset_files(tst_cgroup_new_path, "cpus", "0");<br>oom/oom04.c:            write_cpuset_files(tst_cgroup_new_path, "memory_migrate", "1");<br><div class="gmail_default" style="font-size:small">oom/oom05.c:            write_cpuset_files(tst_cgroup_new_path, "memory_migrate", "1");</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
tst_cgroup_mnt_path is always same as cgroup_dir parameter passed to all functions.<br>
tst_cgroup_get_path() could return pointer to tst_cgroup_pathes->new_path,<br>
  (you just need you call umount before del_path)<br>
<span class="gmail_default" style="font-size:small"></span>tst_cgroup_ctl_knob is set before each use, so it could be local variable too.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">tst_cgroup_ctl_knob can be localized since no other places need it.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>I have no strong preference to shift from v2 to this method, or maybe we<br>
>can try<br>
>to combine together and do more optimize work in the lib side.<br>
<br>
Sounds like we could use 3rd opinion.<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>