Messages in this thread | | | Subject | Re: [RFC PATCH v2 11/17] sched: Basic tracking of matching tasks | From | Subhra Mazumdar <> | Date | Wed, 8 May 2019 11:37:21 -0700 |
| |
On 5/8/19 11:19 AM, Subhra Mazumdar wrote: > > On 5/8/19 8:49 AM, Aubrey Li wrote: >>> Pawan ran an experiment setting up 2 VMs, with one VM doing a >>> parallel kernel build and one VM doing sysbench, >>> limiting both VMs to run on 16 cpu threads (8 physical cores), with >>> 8 vcpu for each VM. >>> Making the fix did improve kernel build time by 7%. >> I'm gonna agree with the patch below, but just wonder if the testing >> result is consistent, >> as I didn't see any improvement in my testing environment. >> >> IIUC, from the code behavior, especially for 2 VMs case(only 2 >> different cookies), the >> per-rq rb tree unlikely has nodes with different cookies, that is, all >> the nodes on this >> tree should have the same cookie, so: >> - if the parameter cookie is equal to the rb tree cookie, we meet a >> match and go the >> third branch >> - else, no matter we go left or right, we can't find a match, and >> we'll return idle thread >> finally. >> >> Please correct me if I was wrong. >> >> Thanks, >> -Aubrey > This is searching in the per core rb tree (rq->core_tree) which can have > 2 different cookies. But having said that, even I didn't see any > improvement with the patch for my DB test case. But logically it is > correct. > Ah, my bad. It is per rq. But still can have 2 different cookies. Not sure why you think it is unlikely?
| |