From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: mingo@elte.hu, tglx@linutronix.de, linux-kernel@vger.kernel.org,
yanmin_zhang@linux.intel.com, seto.hidetoshi@jp.fujitsu.com,
Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 2/2] timers: split process wide cpu clocks/timers
Date: Thu, 5 Feb 2009 22:30:59 +0100 [thread overview]
Message-ID: <20090205213059.GA5050@redhat.com> (raw)
In-Reply-To: <20090205113139.119115519@chello.nl>
On 02/05, Peter Zijlstra wrote:
>
> Change the process wide cpu timers/clocks so that we:
>
> 1) don't mess up the kernel with too many threads,
> 2) don't have a per-cpu allocation for each process,
> 3) have no impact when not used.
>
> In order to accomplish this we're going to split it into two parts:
>
> - clocks; which can take all the time they want since they run
> from user context -- ie. sys_clock_gettime(CLOCK_PROCESS_CPUTIME_ID)
>
> - timers; which need constant time sampling but since they're
> explicity used, the user can pay the overhead.
>
> The clock readout will go back to a full sum of the thread group, while the
> timers will run of a global 'clock' that only runs when needed, so only
> programs that make use of the facility pay the price.
Ah, personally I think this is a very nice idea!
A couple of minor questions, before I try to read this patch more...
> static inline
> -void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times)
> +void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times)
I know, it is silly to complain about the naming, but can't resist.
Now we have both thread_group_cputime() and thread_group_cputimer().
But it is not possible to distinguish them while reading the code.
For example, looks like posix_cpu_timers_exit_group() needs
thread_group_cputimer, not thread_group_cputime, no? But then we can
hit the WARN_ON(!cputimer->running). Afaics.
Hmm... Can't fastpath_timer_check()->thread_group_cputimer() have the
false warning too? Suppose we had the timer, then posix_cpu_timer_del()
removes this timer, but task_cputime_zero(&sig->cputime_expires) still
not true.
> +void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times)
> +{
> + struct sighand_struct *sighand;
> + struct signal_struct *sig;
> + struct task_struct *t;
> +
> + *times = INIT_CPUTIME;
> +
> + rcu_read_lock();
> + sighand = rcu_dereference(tsk->sighand);
> + if (!sighand)
> + goto out;
> +
> + sig = tsk->signal;
I am afraid to be wrong, but it looks like we always call this function
when we know we must have a valid ->sighand/siglock. Perhaps we do not
need any check?
IOW, unless I missed something we should not just return if there is no
->sighand or ->signal, this just hides the problem while we should fix
the caller.
> + * Enable the process wide cpu timer accounting.
> + *
> + * serialized using ->sighand->siglock
> + */
> +static void start_process_timers(struct task_struct *tsk)
> +{
> + tsk->signal->cputimer.running = 1;
> + barrier();
> +}
> +
> +/*
> + * Release the process wide timer accounting -- timer stops ticking when
> + * nobody cares about it.
> + *
> + * serialized using ->sighand->siglock
> + */
> +static void stop_process_timers(struct task_struct *tsk)
> +{
> + tsk->signal->cputimer.running = 0;
> + barrier();
> +}
Could you explain these barriers?
And, I am a bit lost... set_process_cpu_timer() does cpu_timer_sample_group(),
but posix_cpu_timer_set() does cpu_clock_sample_group() in !CPUCLOCK_PERTHREAD
case, could you confirm this is correct?
Oleg.
next prev parent reply other threads:[~2009-02-05 21:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-05 11:24 [PATCH 0/2] fix the itimer regression (BZ 12618) Peter Zijlstra
2009-02-05 11:24 ` [PATCH 1/2] signal: re-add dead task accumulation stats Peter Zijlstra
2009-02-05 11:24 ` [PATCH 2/2] timers: split process wide cpu clocks/timers Peter Zijlstra
2009-02-05 21:30 ` Oleg Nesterov [this message]
2009-02-05 22:20 ` Peter Zijlstra
2009-02-05 12:06 ` [PATCH 0/2] fix the itimer regression (BZ 12618) Ingo Molnar
2009-02-06 4:51 ` Zhang, Yanmin
2009-02-06 15:18 ` Ingo Molnar
2009-02-09 6:46 ` Lin Ming
2009-02-09 21:47 ` Ingo Molnar
2009-02-10 5:52 ` Mike Galbraith
2009-02-10 12:47 ` Peter Zijlstra
2009-02-11 2:09 ` Zhang, Yanmin
2009-02-12 11:05 ` Ingo Molnar
2009-02-13 9:15 ` Lin Ming
2009-02-13 10:06 ` Ingo Molnar
2009-02-11 13:11 ` Ingo Molnar
2009-02-11 13:27 ` Peter Zijlstra
2009-02-10 2:48 ` Lin Ming
2009-02-11 12:59 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090205213059.GA5050@redhat.com \
--to=oleg@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tglx@linutronix.de \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.