Messages in this thread | | | Subject | Re: [RFC][PATCH 03/16] sched: Wrap rq::lock access | From | Subhra Mazumdar <> | Date | Thu, 4 Apr 2019 18:30:45 -0700 |
| |
> We tried to comment those lines and it doesn’t seem to get rid of the > performance regression we are seeing. > Can you elaborate a bit more about the test you are performing, what kind of > resources it uses ? I am running 1 and 2 Oracle DB instances each running TPC-C workload. The clients driving the instances also run in same node. Each server client pair is put in each cpu group and tagged. > Can you also try to replicate our test and see if you see the same problem ? > > cgcreate -g cpu,cpuset:set1 > cat /sys/devices/system/cpu/cpu{0,2,4,6}/topology/thread_siblings_list > 0,36 > 2,38 > 4,40 > 6,42 > > echo "0,2,4,6,36,38,40,42" | sudo tee /sys/fs/cgroup/cpuset/set1/cpuset.cpus > echo 0 | sudo tee /sys/fs/cgroup/cpuset/set1/cpuset.mems > > echo 1 | sudo tee /sys/fs/cgroup/cpu,cpuacct/set1/cpu.tag > > sysbench --test=fileio prepare > cgexec -g cpu,cpuset:set1 sysbench --threads=4 --test=fileio \ > --file-test-mode=seqwr run > > The reason we create a cpuset is to narrow down the investigation to just 4 > cores on a highly powerful machine. It might not be needed if testing on a > smaller machine. With this sysbench test I am not seeing any improvement with removing the condition. Also with hackbench I found it makes no difference but that has much lower regression to begin with (18%) > > Julien
| |