On 05/15/2014 08:11 PM, Johannes Weiner wrote:
> On Wed, May 14, 2014 at 06:36:48PM -0400, Tejun Heo wrote:
>> On Wed, May 14, 2014 at 07:10:51PM +0200, Peter Zijlstra wrote:
>>> On Wed, May 14, 2014 at 01:02:38PM -0400, Tejun Heo wrote:
On Wed, May 14, 2014 at 04:00:34PM +0200, Peter Zijlstra
On Fri, May 16, 2014 at 01:01:53PM +0200, Juri Lelli wrote:
> Are the comments I proposed to add overdoing?
Dunno, might be helpful, if you post them as a proper patch I'll press
'A'.
> Apart from this,
>
> Acked-by: Juri Lelli
Thanks!
pgpJQlRFnZSr6.pgp
Description: PGP signature
On Fri, 16 May 2014 12:43:36 +0200
Peter Zijlstra wrote:
>
> OK I made that..
>
Are the comments I proposed to add overdoing?
Apart from this,
Acked-by: Juri Lelli
Thanks!
- Juri
> ---
>
> Subject: sched/cpudl: Replace NR_CPUS arrays
> From: Peter Zijlstra
> Date: Wed May 14 16:13:56 C
OK I made that..
---
Subject: sched/cpudl: Replace NR_CPUS arrays
From: Peter Zijlstra
Date: Wed May 14 16:13:56 CEST 2014
Tejun reported that his resume was failing due to order-3 allocations
from sched_domain building.
Replace the NR_CPUS arrays in there with a dynamically allocated
array.
On Thu, May 15, 2014 at 10:41:14AM -0400, Johannes Weiner wrote:
> Is it necessary that resume paths allocate at all? Freeing at suspend
> what you have to reallocate at resume is asking for trouble. It's not
> just higher order allocations, either, even order-0 allocations are
> less reliable wi
On Wed, May 14, 2014 at 06:36:48PM -0400, Tejun Heo wrote:
> On Wed, May 14, 2014 at 07:10:51PM +0200, Peter Zijlstra wrote:
> > On Wed, May 14, 2014 at 01:02:38PM -0400, Tejun Heo wrote:
> > > On Wed, May 14, 2014 at 04:00:34PM +0200, Peter Zijlstra wrote:
> > > > Does something like the below hel
On Thu, 15 May 2014 10:51:56 +0200
Peter Zijlstra wrote:
> On Thu, May 15, 2014 at 10:40:55AM +0200, Juri Lelli wrote:
> > Hi,
> >
> > > @@ -37,10 +38,7 @@ static inline int dl_time_before(u64 a, u64 b)
> > >
> > > static void cpudl_exchange(struct cpudl *cp, int a, int b)
> > > {
> > > - in
On Wed, May 14, 2014 at 06:36:48PM -0400, Tejun Heo wrote:
> The patches are URL encoded.
*sigh*.. evo used to do that, and now I think mutt does it because I've
set up the whole GPG thing.
All my scripts already automagically decode it so I hadn't noticed.
I can give you some awk that undoes i
On Thu, May 15, 2014 at 10:40:55AM +0200, Juri Lelli wrote:
> Hi,
>
> > @@ -37,10 +38,7 @@ static inline int dl_time_before(u64 a, u64 b)
> >
> > static void cpudl_exchange(struct cpudl *cp, int a, int b)
> > {
> > - int cpu_a = cp->elements[a].cpu, cpu_b = cp->elements[b].cpu;
> > -
> >
Hi,
On Wed, 14 May 2014 16:00:34 +0200
Peter Zijlstra wrote:
> On Fri, May 09, 2014 at 12:04:55PM -0400, Tejun Heo wrote:
> > Hello, guys.
> >
> > So, after resuming from suspend, I found my build jobs can not migrate
> > away from the CPU it started on and thus just making use of single
> > co
On Wed, May 14, 2014 at 07:10:51PM +0200, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 01:02:38PM -0400, Tejun Heo wrote:
> > On Wed, May 14, 2014 at 04:00:34PM +0200, Peter Zijlstra wrote:
> > > Does something like the below help any? I noticed those things (cpudl
> > > and cpupri) had [NR_CPUS
On Wed, May 14, 2014 at 01:02:38PM -0400, Tejun Heo wrote:
> On Wed, May 14, 2014 at 04:00:34PM +0200, Peter Zijlstra wrote:
> > Does something like the below help any? I noticed those things (cpudl
> > and cpupri) had [NR_CPUS] arrays, which is always 'fun'.
> >
> > The below is a mostly no thoug
On Wed, May 14, 2014 at 04:00:34PM +0200, Peter Zijlstra wrote:
> Does something like the below help any? I noticed those things (cpudl
> and cpupri) had [NR_CPUS] arrays, which is always 'fun'.
>
> The below is a mostly no thought involved conversion of cpudl which
> boots, I'll also do cpupri an
On Wed, May 14, 2014 at 04:00:34PM +0200, Peter Zijlstra wrote:
> The below is a mostly no thought involved conversion of cpudl which
^^^
> boots, I'll also do cpupri and then actually stare at the algorithms to
> see if I didn't make any obvious fails.
>
>
On Fri, May 09, 2014 at 12:04:55PM -0400, Tejun Heo wrote:
> Hello, guys.
>
> So, after resuming from suspend, I found my build jobs can not migrate
> away from the CPU it started on and thus just making use of single
> core. It turns out the scheduler failed to build sched domains due to
> order
On Fri, May 09, 2014 at 12:04:55PM -0400, Tejun Heo wrote:
> It looks like the allocation is for a temp buffer and there are also
> percpu allocations going on. Maybe just allocate the buffers on boot
> and keep them around?
Its not a scratch buffer, but we could certainly try and keep it around
16 matches
Mail list logo
