lkml.org 
[lkml]   [2015]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/3] sched, timer: Use atomics for thread_group_cputimer to improve scalability

* Jason Low <jason.low2@hp.com> wrote:

> While running a database workload, we found a scalability issue with itimers.
>
> Much of the problem was caused by the thread_group_cputimer spinlock.

So I'm fine with the basic principle, but in the hope that maybe
posix-cpu-timers will grow similar optimizations in the future, it
would help to have the new data type factored out better, not
open-coded:

> struct thread_group_cputimer {
> - struct task_cputime cputime;
> + atomic64_t utime;
> + atomic64_t stime;
> + atomic64_t sum_exec_runtime;
> int running;
> - raw_spinlock_t lock;
> };

So after your changes we still have a separate:

struct task_cputime {
cputime_t utime;
cputime_t stime;
unsigned long long sum_exec_runtime;
};

Which then weirdly overlaps with a different structure on a different
abstraction level:

struct thread_group_cputimer {
atomic64_t utime;
atomic64_t stime;
atomic64_t sum_exec_runtime;
int running;
};

So I think it would be more obvious what's going on if we introduced
an atomic task_cputime structure:

struct task_cputime_atomic {
atomic64_t utime;
atomic64_t stime;
atomic64_t sum_exec_runtime;
};

and put that into 'struct thread_group_cputimer':

struct thread_group_cputimer {
struct task_cputime_atomic cputime_atomic;
int running;
};

Maybe even factor out the main update and reading methods into
expressively named helper inlines?

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-04-15 10:01    [W:0.187 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site