Messages in this thread | | | Subject | Re: [RFC][PATCH 00/16] sched: Core scheduling | From | Subhra Mazumdar <> | Date | Thu, 21 Feb 2019 10:44:35 -0800 |
| |
On 2/21/19 6:03 AM, Peter Zijlstra wrote: > On Wed, Feb 20, 2019 at 06:53:08PM -0800, Subhra Mazumdar wrote: >> On 2/18/19 9:49 AM, Linus Torvalds wrote: >>> On Mon, Feb 18, 2019 at 9:40 AM Peter Zijlstra <peterz@infradead.org> wrote: >>>> However; whichever way around you turn this cookie; it is expensive and nasty. >>> Do you (or anybody else) have numbers for real loads? >>> >>> Because performance is all that matters. If performance is bad, then >>> it's pointless, since just turning off SMT is the answer. >>> >>> Linus >> I tested 2 Oracle DB instances running OLTP on a 2 socket 44 cores system. >> This is on baremetal, no virtualization. > I'm thinking oracle schedules quite a bit, right? Then you get massive > overhead (as shown). Yes. In terms of idleness we have:
Users baseline core_sched 16 67% 70% 24 53% 59% 32 41% 49%
So there is more idleness with core sched which is understandable as there can be forced idleness. The other part contributing to regression is most likely overhead. > > The thing with virt workloads is that if they don't VMEXIT lots, they > also don't schedule lots (the vCPU stays running, nested scheduler > etc..). I plan to run some VM workloads. > > Also; like I wrote, it is quite possible there is some sibling rivalry > here, which can cause excessive rescheduling. Someone would have to > trace a workload and check. > > My older patches had a condition that would not preempt a task for a > little while, such that it might make _some_ progress, these patches > don't have that (yet). >
| |