On Thu, 2016-04-28 at 14:00 +0200, Peter Zijlstra wrote:
> On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> > sched: ratelimit nohz
> >
> > Entering nohz code on every micro-idle is too expensive to bear.
> >
> > Signed-off-by: Mike Galbraith
>
> > +int sched_needs_cpu(int cpu)
On Thu, 2016-04-28 at 14:00 +0200, Peter Zijlstra wrote:
> On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> > sched: ratelimit nohz
> >
> > Entering nohz code on every micro-idle is too expensive to bear.
> >
> > Signed-off-by: Mike Galbraith
>
> > +int sched_needs_cpu(int cpu)
On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> sched: ratelimit nohz
>
> Entering nohz code on every micro-idle is too expensive to bear.
>
> Signed-off-by: Mike Galbraith
> +int sched_needs_cpu(int cpu)
> +{
> + if (tick_nohz_full_cpu(cpu))
> + return 0;
> +
On Wed, Apr 13, 2016 at 05:40:20AM +0200, Mike Galbraith wrote:
> On Tue, 2016-04-12 at 22:45 +0100, Matt Fleming wrote:
> > On Sat, 09 Apr, at 01:30:34PM, Chris Mason wrote:
> > >
> > > [ nohz throttling patch ]
> > >
> > > I tested the nohz throttle two different ways, first with schbench's
> >
On Tue, 2016-04-12 at 22:45 +0100, Matt Fleming wrote:
> On Sat, 09 Apr, at 01:30:34PM, Chris Mason wrote:
> >
> > [ nohz throttling patch ]
> >
> > I tested the nohz throttle two different ways, first with schbench's
> > pipe simulation, it's easily 8% faster with messages bouncing between
> > c
On Sat, 09 Apr, at 01:30:34PM, Chris Mason wrote:
>
> [ nohz throttling patch ]
>
> I tested the nohz throttle two different ways, first with schbench's
> pipe simulation, it's easily 8% faster with messages bouncing between
> cpus.
>
> In production it's hard to pick a single number because the
On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> > On Tue, 2016-04-05 at 14:08 -0400, Chris Mason wrote:
>
> > Now, on to the patch. I pushed some code around and narrowed the
> > problem down to select_idle_sibling() We have cores going into and out
> > of idle fast enough tha
On Tue, Apr 05, 2016 at 02:08:22PM -0400, Chris Mason wrote:
> Hi everyone,
>
> We're porting the fb kernel up to 4.5, and one of our last few out-of-tree
> patches is a hack to try harder to find idle cpus when waking up tasks.
> This helps in pretty much every workload we run, mostly because the
On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote:
> > On Tue, 2016-04-05 at 14:08 -0400, Chris Mason wrote:
>
> > Now, on to the patch. I pushed some code around and narrowed the
> > problem down to select_idle_sibling() We have cores going into and out
> > of idle fast enough tha
> On Tue, 2016-04-05 at 14:08 -0400, Chris Mason wrote:
> Now, on to the patch. I pushed some code around and narrowed the
> problem down to select_idle_sibling() We have cores going into and out
> of idle fast enough that even this cut our latencies in half:
Are you using NO_HZ? If so, you m
On Tue, Apr 05, 2016 at 09:03:02PM +0100, Matt Fleming wrote:
> On Tue, 05 Apr, at 02:08:22PM, Chris Mason wrote:
> >
> > I started with a small-ish program to benchmark wakeup latencies. The
> > basic idea is a bunch of worker threads who sit around and burn CPU.
> > Every once and a while they
On 2016-04-05 04:03 PM, Matt Fleming wrote:
> On Tue, 05 Apr, at 02:08:22PM, Chris Mason wrote:
>>
>> I started with a small-ish program to benchmark wakeup latencies. The
>> basic idea is a bunch of worker threads who sit around and burn CPU.
>> Every once and a while they send a message to a m
On Tue, 05 Apr, at 02:08:22PM, Chris Mason wrote:
>
> I started with a small-ish program to benchmark wakeup latencies. The
> basic idea is a bunch of worker threads who sit around and burn CPU.
> Every once and a while they send a message to a message thread.
This reminds me of something I've
On Tue, Apr 05, 2016 at 02:43:09PM -0400, Bastien Bastien Philbert wrote:
> On Tue, Apr 5, 2016 at 2:08 PM, Chris Mason wrote:
[ ... ]
> >
> > I tried a few variations on select_idle_sibling() that preserved the
> > underlying goal of returning idle cores before idle SMT threads. They
> > were
On Tue, Apr 5, 2016 at 2:08 PM, Chris Mason wrote:
> Hi everyone,
>
> We're porting the fb kernel up to 4.5, and one of our last few out-of-tree
> patches is a hack to try harder to find idle cpus when waking up tasks.
> This helps in pretty much every workload we run, mostly because they all
> ge
Hi everyone,
We're porting the fb kernel up to 4.5, and one of our last few out-of-tree
patches is a hack to try harder to find idle cpus when waking up tasks.
This helps in pretty much every workload we run, mostly because they all
get tuned with a similar setup:
1) find the load where latencies
16 matches
Mail list logo
