[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1405272245050.21720@ionos.tec.linutronix.de>
Date: Tue, 27 May 2014 22:53:24 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Libo Chen <libo.chen@...wei.com>
cc: Mike Galbraith <umgwanakikbuti@...il.com>, mingo@...e.hu,
LKML <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Li Zefan <lizefan@...wei.com>, peterz@...radead.org
Subject: Re: balance storm
On Tue, 27 May 2014, Libo Chen wrote:
> On 2014/5/27 17:55, Mike Galbraith wrote:
> > On Tue, 2014-05-27 at 15:56 +0800, Libo Chen wrote:
> >> > On 2014/5/26 22:19, Mike Galbraith wrote:
> >>> > > On Mon, 2014-05-26 at 20:16 +0800, Libo Chen wrote:
> >>>> > >> On 2014/5/26 13:11, Mike Galbraith wrote:
> >>> > >
> >>>>> > >>> Your synthetic test is the absolute worst case scenario. There has to
> >>>>> > >>> be work between wakeups for select_idle_sibling() to have any chance
> >>>>> > >>> whatsoever of turning in a win. At 0 work, it becomes 100% overhead.
> >>>> > >>
> >>>> > >> not synthetic, it is a real problem in our product. under no load, waste
> >>>> > >> much cpu time.
> >>> > >
> >>> > > What happens in your product if you apply the commit I pointed out?
> >> >
> >> > under no load, cpu usage is up to 60%, but the same apps cost 10% on
> >> > susp sp1. The apps use a lot of timer.
> > Something is rotten. 3.14-rt contains that commit, I ran your test with
> > 256 threads on 64 core box, saw ~4%.
> >
> > Putting master/nopreempt config on box and doing the same test, box is
> > chewing up truckloads of CPU, but not from migrations.
> >
> > perf top -g --sort=symbol
> in my box:
>
> perf top -g --sort=symbol
>
> Events: 3K cycles
> 73.27% [k] read_hpet
Why is that machine using read_hpet() ?
Please provide the output of
# dmesg | grep -i tsc
and
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
and
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists