On Fri, Aug 15, 2014 at 04:26:01PM +0200, Oleg Nesterov wrote:
> On 08/15, Frederic Weisbecker wrote:
> >
> > 2014-08-14 16:39 GMT+02:00 Oleg Nesterov :
> > > On 08/14, Frederic Weisbecker wrote:
> > >>
> > >> I mean the read side doesn't use a lock with seqlocks. It's only made
> > >> of barriers
On 08/15, Rik van Riel wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/15/2014 12:49 PM, Oleg Nesterov wrote:
>
> > Just in case... Yes, sure, "seqlock_t stats_lock" is more scalable.
> > Just I do not know it's worth the trouble.
>
> If we don't know whether it is worth the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/15/2014 12:49 PM, Oleg Nesterov wrote:
> Just in case... Yes, sure, "seqlock_t stats_lock" is more scalable.
> Just I do not know it's worth the trouble.
If we don't know whether it is worth the trouble, it is probably best
to stick to a
On 08/15, Oleg Nesterov wrote:
>
> However, if we only want to make sys_times() more scalable(), then
> perhaps the "lockless" version of thread_group_cputime() makes more
> sense. And given that do_sys_times() uses current we can simplify it;
> is_dead is not possible and we do not need to take
On 08/15, Peter Zijlstra wrote:
>
> Also; why do we care about PROCESS_CPUTIME? People should really not use
> it. What are the 'valid' usecases you guys care about?
I do not really know. IIUC, the problematic usecase is sys_times().
I agree with Mike, "don't do this if you have a lot of
On 08/14, Rik van Riel wrote:
>
> @@ -288,18 +288,31 @@ void thread_group_cputime(struct task_struct *tsk,
> struct task_cputime *times)
> struct signal_struct *sig = tsk->signal;
> cputime_t utime, stime;
> struct task_struct *t;
> -
> - times->utime = sig->utime;
> -
On 08/15, Frederic Weisbecker wrote:
>
> 2014-08-14 16:39 GMT+02:00 Oleg Nesterov :
> > On 08/14, Frederic Weisbecker wrote:
> >>
> >> I mean the read side doesn't use a lock with seqlocks. It's only made
> >> of barriers and sequence numbers to ensure the reader doesn't read
> >> some
On Fri, Aug 15, 2014 at 11:37:33AM +0200, Mike Galbraith wrote:
> On Fri, 2014-08-15 at 08:28 +0200, Peter Zijlstra wrote:
> > On Fri, Aug 15, 2014 at 07:19:31AM +0200, Mike Galbraith wrote:
> > > For the N threads doing this on N cores case, seems rq->lock hammering
> > > will still be a source
On Fri, 2014-08-15 at 08:28 +0200, Peter Zijlstra wrote:
> On Fri, Aug 15, 2014 at 07:19:31AM +0200, Mike Galbraith wrote:
> > For the N threads doing this on N cores case, seems rq->lock hammering
> > will still be a source of major box wide pain. Is there any correctness
> > reason to add up
On Fri, Aug 15, 2014 at 07:19:31AM +0200, Mike Galbraith wrote:
> For the N threads doing this on N cores case, seems rq->lock hammering
> will still be a source of major box wide pain. Is there any correctness
> reason to add up unaccounted ->on_cpu beans, or is that just value
> added?
That
On Fri, Aug 15, 2014 at 07:19:31AM +0200, Mike Galbraith wrote:
For the N threads doing this on N cores case, seems rq-lock hammering
will still be a source of major box wide pain. Is there any correctness
reason to add up unaccounted -on_cpu beans, or is that just value
added?
That delta
On Fri, 2014-08-15 at 08:28 +0200, Peter Zijlstra wrote:
On Fri, Aug 15, 2014 at 07:19:31AM +0200, Mike Galbraith wrote:
For the N threads doing this on N cores case, seems rq-lock hammering
will still be a source of major box wide pain. Is there any correctness
reason to add up
On Fri, Aug 15, 2014 at 11:37:33AM +0200, Mike Galbraith wrote:
On Fri, 2014-08-15 at 08:28 +0200, Peter Zijlstra wrote:
On Fri, Aug 15, 2014 at 07:19:31AM +0200, Mike Galbraith wrote:
For the N threads doing this on N cores case, seems rq-lock hammering
will still be a source of major
On 08/15, Frederic Weisbecker wrote:
2014-08-14 16:39 GMT+02:00 Oleg Nesterov o...@redhat.com:
On 08/14, Frederic Weisbecker wrote:
I mean the read side doesn't use a lock with seqlocks. It's only made
of barriers and sequence numbers to ensure the reader doesn't read
some
On 08/14, Rik van Riel wrote:
@@ -288,18 +288,31 @@ void thread_group_cputime(struct task_struct *tsk,
struct task_cputime *times)
struct signal_struct *sig = tsk-signal;
cputime_t utime, stime;
struct task_struct *t;
-
- times-utime = sig-utime;
- times-stime =
On 08/15, Peter Zijlstra wrote:
Also; why do we care about PROCESS_CPUTIME? People should really not use
it. What are the 'valid' usecases you guys care about?
I do not really know. IIUC, the problematic usecase is sys_times().
I agree with Mike, don't do this if you have a lot of threads.
On 08/15, Oleg Nesterov wrote:
However, if we only want to make sys_times() more scalable(), then
perhaps the lockless version of thread_group_cputime() makes more
sense. And given that do_sys_times() uses current we can simplify it;
is_dead is not possible and we do not need to take -siglock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/15/2014 12:49 PM, Oleg Nesterov wrote:
Just in case... Yes, sure, seqlock_t stats_lock is more scalable.
Just I do not know it's worth the trouble.
If we don't know whether it is worth the trouble, it is probably best
to stick to a
On 08/15, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/15/2014 12:49 PM, Oleg Nesterov wrote:
Just in case... Yes, sure, seqlock_t stats_lock is more scalable.
Just I do not know it's worth the trouble.
If we don't know whether it is worth the trouble, it is
On Fri, Aug 15, 2014 at 04:26:01PM +0200, Oleg Nesterov wrote:
On 08/15, Frederic Weisbecker wrote:
2014-08-14 16:39 GMT+02:00 Oleg Nesterov o...@redhat.com:
On 08/14, Frederic Weisbecker wrote:
I mean the read side doesn't use a lock with seqlocks. It's only made
of barriers and
On Thu, 2014-08-14 at 19:48 +0200, Oleg Nesterov wrote:
> On 08/14, Oleg Nesterov wrote:
> >
> > OK, lets forget about alternative approach for now. We can reconsider
> > it later. At least I have to admit that seqlock is more straighforward.
>
> Yes.
>
> But just for record, the "lockless"
2014-08-14 16:39 GMT+02:00 Oleg Nesterov :
> On 08/14, Frederic Weisbecker wrote:
>>
>> 2014-08-14 3:57 GMT+02:00 Rik van Riel :
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
>> >> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik
On Thu, 14 Aug 2014 18:12:47 +0200
Oleg Nesterov wrote:
> Or you can expand the scope of write_seqlock/write_sequnlock, so that
> __unhash_process in called from inside the critical section. This looks
> simpler at first glance.
>
> Hmm, wait, it seems there is yet another problem ;) Afaics,
On 08/14, Rik van Riel wrote:
>
> On 08/14/2014 02:15 PM, Oleg Nesterov wrote:
> > On 08/14, Rik van Riel wrote:
> >>
> >> On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
> >>>
> >>> Or you can expand the scope of write_seqlock/write_sequnlock, so that
> >>> __unhash_process in called from inside the
On 08/14/2014 02:15 PM, Oleg Nesterov wrote:
> On 08/14, Rik van Riel wrote:
>>
>> On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
>>>
>>> Or you can expand the scope of write_seqlock/write_sequnlock, so that
>>> __unhash_process in called from inside the critical section. This looks
>>> simpler at
On 08/14, Oleg Nesterov wrote:
>
> But just for record, the "lockless" version doesn't look that bad to me,
>
> void thread_group_cputime(struct task_struct *tsk, struct task_cputime
> *times)
> {
> struct signal_struct *sig = tsk->signal;
> bool lockless,
On 08/14, Rik van Riel wrote:
>
> On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
> >
> > Or you can expand the scope of write_seqlock/write_sequnlock, so that
> > __unhash_process in called from inside the critical section. This looks
> > simpler at first glance.
>
> The problem with that is that
On 08/14, Oleg Nesterov wrote:
>
> OK, lets forget about alternative approach for now. We can reconsider
> it later. At least I have to admit that seqlock is more straighforward.
Yes.
But just for record, the "lockless" version doesn't look that bad to me,
void
On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
> On 08/14, Rik van Riel wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 08/14/2014 10:24 AM, Oleg Nesterov wrote:
>>> On 08/13, Rik van Riel wrote:
@@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms) {
On 08/14, Rik van Riel wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/14/2014 10:24 AM, Oleg Nesterov wrote:
> > On 08/13, Rik van Riel wrote:
> >>
> >> @@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms) {
> >> cputime_t tgutime, tgstime, cutime, cstime;
> >>
> >> -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/14/2014 10:24 AM, Oleg Nesterov wrote:
> On 08/13, Rik van Riel wrote:
>>
>> @@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms) {
>> cputime_t tgutime, tgstime, cutime, cstime;
>>
>> -spin_lock_irq(>sighand->siglock);
>>
On 08/14, Frederic Weisbecker wrote:
>
> 2014-08-14 3:57 GMT+02:00 Rik van Riel :
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
> >> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
> >>
> >> I'm worried about such
On 08/13, Rik van Riel wrote:
>
> @@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms)
> {
> cputime_t tgutime, tgstime, cutime, cstime;
>
> - spin_lock_irq(>sighand->siglock);
> thread_group_cputime_adjusted(current, , );
> cutime = current->signal->cutime;
>
On 08/14, Frederic Weisbecker wrote:
>
> 2014-08-14 15:22 GMT+02:00 Oleg Nesterov :
> > On 08/13, Rik van Riel wrote:
> >>
> >> @@ -646,6 +646,7 @@ struct signal_struct {
> >>* Live threads maintain their own counters and add to these
> >>* in __exit_signal, except for the group
2014-08-14 15:22 GMT+02:00 Oleg Nesterov :
> On 08/13, Rik van Riel wrote:
>>
>> On Wed, 13 Aug 2014 20:45:11 +0200
>> Oleg Nesterov wrote:
>>
>> > That said, it is not that I am really sure that seqcount_t in ->signal
>> > is actually worse, not to mention that this is subjective anyway. IOW,
>>
2014-08-14 3:57 GMT+02:00 Rik van Riel :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
>> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
>>> --- a/kernel/time/posix-cpu-timers.c +++
>>> b/kernel/time/posix-cpu-timers.c @@
On 08/13, Rik van Riel wrote:
>
> On Wed, 13 Aug 2014 20:45:11 +0200
> Oleg Nesterov wrote:
>
> > That said, it is not that I am really sure that seqcount_t in ->signal
> > is actually worse, not to mention that this is subjective anyway. IOW,
> > I am not going to really fight with your approach
On 08/13, Rik van Riel wrote:
On Wed, 13 Aug 2014 20:45:11 +0200
Oleg Nesterov o...@redhat.com wrote:
That said, it is not that I am really sure that seqcount_t in -signal
is actually worse, not to mention that this is subjective anyway. IOW,
I am not going to really fight with your
2014-08-14 3:57 GMT+02:00 Rik van Riel r...@redhat.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
--- a/kernel/time/posix-cpu-timers.c +++
b/kernel/time/posix-cpu-timers.c @@
2014-08-14 15:22 GMT+02:00 Oleg Nesterov o...@redhat.com:
On 08/13, Rik van Riel wrote:
On Wed, 13 Aug 2014 20:45:11 +0200
Oleg Nesterov o...@redhat.com wrote:
That said, it is not that I am really sure that seqcount_t in -signal
is actually worse, not to mention that this is subjective
On 08/14, Frederic Weisbecker wrote:
2014-08-14 15:22 GMT+02:00 Oleg Nesterov o...@redhat.com:
On 08/13, Rik van Riel wrote:
@@ -646,6 +646,7 @@ struct signal_struct {
* Live threads maintain their own counters and add to these
* in __exit_signal, except for the group
On 08/13, Rik van Riel wrote:
@@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms)
{
cputime_t tgutime, tgstime, cutime, cstime;
- spin_lock_irq(current-sighand-siglock);
thread_group_cputime_adjusted(current, tgutime, tgstime);
cutime = current-signal-cutime;
On 08/14, Frederic Weisbecker wrote:
2014-08-14 3:57 GMT+02:00 Rik van Riel r...@redhat.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
I'm worried about such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/14/2014 10:24 AM, Oleg Nesterov wrote:
On 08/13, Rik van Riel wrote:
@@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms) {
cputime_t tgutime, tgstime, cutime, cstime;
-spin_lock_irq(current-sighand-siglock);
On 08/14, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/14/2014 10:24 AM, Oleg Nesterov wrote:
On 08/13, Rik van Riel wrote:
@@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms) {
cputime_t tgutime, tgstime, cutime, cstime;
-
On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
On 08/14, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/14/2014 10:24 AM, Oleg Nesterov wrote:
On 08/13, Rik van Riel wrote:
@@ -862,11 +862,9 @@ void do_sys_times(struct tms *tms) {
cputime_t tgutime, tgstime,
On 08/14, Oleg Nesterov wrote:
OK, lets forget about alternative approach for now. We can reconsider
it later. At least I have to admit that seqlock is more straighforward.
Yes.
But just for record, the lockless version doesn't look that bad to me,
void thread_group_cputime(struct
On 08/14, Rik van Riel wrote:
On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
Or you can expand the scope of write_seqlock/write_sequnlock, so that
__unhash_process in called from inside the critical section. This looks
simpler at first glance.
The problem with that is that
On 08/14, Oleg Nesterov wrote:
But just for record, the lockless version doesn't look that bad to me,
void thread_group_cputime(struct task_struct *tsk, struct task_cputime
*times)
{
struct signal_struct *sig = tsk-signal;
bool lockless, is_dead;
On 08/14/2014 02:15 PM, Oleg Nesterov wrote:
On 08/14, Rik van Riel wrote:
On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
Or you can expand the scope of write_seqlock/write_sequnlock, so that
__unhash_process in called from inside the critical section. This looks
simpler at first glance.
On 08/14, Rik van Riel wrote:
On 08/14/2014 02:15 PM, Oleg Nesterov wrote:
On 08/14, Rik van Riel wrote:
On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
Or you can expand the scope of write_seqlock/write_sequnlock, so that
__unhash_process in called from inside the critical section.
On Thu, 14 Aug 2014 18:12:47 +0200
Oleg Nesterov o...@redhat.com wrote:
Or you can expand the scope of write_seqlock/write_sequnlock, so that
__unhash_process in called from inside the critical section. This looks
simpler at first glance.
Hmm, wait, it seems there is yet another problem ;)
2014-08-14 16:39 GMT+02:00 Oleg Nesterov o...@redhat.com:
On 08/14, Frederic Weisbecker wrote:
2014-08-14 3:57 GMT+02:00 Rik van Riel r...@redhat.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
On Wed, Aug 13, 2014 at 05:03:24PM
On Thu, 2014-08-14 at 19:48 +0200, Oleg Nesterov wrote:
On 08/14, Oleg Nesterov wrote:
OK, lets forget about alternative approach for now. We can reconsider
it later. At least I have to admit that seqlock is more straighforward.
Yes.
But just for record, the lockless version doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
>> --- a/kernel/time/posix-cpu-timers.c +++
>> b/kernel/time/posix-cpu-timers.c @@ -272,22 +272,8 @@ static int
>>
On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
> --- a/kernel/time/posix-cpu-timers.c
> +++ b/kernel/time/posix-cpu-timers.c
> @@ -272,22 +272,8 @@ static int posix_cpu_clock_get_task(struct task_struct
> *tsk,
> if (same_thread_group(tsk, current))
>
On Wed, 13 Aug 2014 20:45:11 +0200
Oleg Nesterov wrote:
> That said, it is not that I am really sure that seqcount_t in ->signal
> is actually worse, not to mention that this is subjective anyway. IOW,
> I am not going to really fight with your approach ;)
This is what it looks like, on top of
On Wed, 13 Aug 2014 20:45:11 +0200
Oleg Nesterov wrote:
> That said, it is not that I am really sure that seqcount_t in ->signal
> is actually worse, not to mention that this is subjective anyway. IOW,
> I am not going to really fight with your approach ;)
This is what it looks like, on top of
On Wed, 13 Aug 2014 20:45:11 +0200
Oleg Nesterov o...@redhat.com wrote:
That said, it is not that I am really sure that seqcount_t in -signal
is actually worse, not to mention that this is subjective anyway. IOW,
I am not going to really fight with your approach ;)
This is what it looks like,
On Wed, 13 Aug 2014 20:45:11 +0200
Oleg Nesterov o...@redhat.com wrote:
That said, it is not that I am really sure that seqcount_t in -signal
is actually worse, not to mention that this is subjective anyway. IOW,
I am not going to really fight with your approach ;)
This is what it looks like,
On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -272,22 +272,8 @@ static int posix_cpu_clock_get_task(struct task_struct
*tsk,
if (same_thread_group(tsk, current))
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
--- a/kernel/time/posix-cpu-timers.c +++
b/kernel/time/posix-cpu-timers.c @@ -272,22 +272,8 @@ static int
62 matches
Mail list logo
