All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Dave Anderson <anderson@redhat.com>,
	Ingo Molnar <mingo@kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Wang Shu <shuwang@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] introduce for_each_process_thread_{break,continue}() helpers
Date: Wed, 3 Aug 2016 22:26:09 +0200	[thread overview]
Message-ID: <20160803202609.GA11419@redhat.com> (raw)
In-Reply-To: <20160802115850.GI6862@twins.programming.kicks-ass.net>

Thanks for review and sorry for delay, I am travelling till the end of this week.

On 08/02, Peter Zijlstra wrote:
>
> On Mon, Jul 25, 2016 at 06:23:48PM +0200, Oleg Nesterov wrote:
> > +void for_each_process_thread_continue(struct task_struct **p_leader,
> > +				      struct task_struct **p_thread)
> > +{
> > +	struct task_struct *leader = *p_leader, *thread = *p_thread;
> > +	struct task_struct *prev, *next;
> > +	u64 start_time;
> > +
> > +	if (pid_alive(thread)) {
> > +		/* mt exec could change the leader */
> > +		*p_leader = thread->group_leader;
> > +	} else if (pid_alive(leader)) {
> > +		start_time = thread->start_time;
> > +		prev = leader;
> > +
> > +		for_each_thread(leader, next) {
> > +			if (next->start_time > start_time)
> > +				break;
> > +			prev = next;
> > +		}
>
> This,
>
> > +		*p_thread = prev;
> > +	} else {
> > +		start_time = leader->start_time;
> > +		prev = &init_task;
> > +
> > +		for_each_process(next) {
> > +			if (next->start_time > start_time)
> > +				break;
> > +			prev = next;
> > +		}
>
> and this, could be 'SPEND_TOO_MUCH_TIME' all by themselves.
>
> Unlikely though, nor do I really have a better suggestion :/

Yeees, I don't think this can actually hurt "in practice", but I agree, compared
to rcu_lock_break() this is only bounded by PID_MAX_DEFAULT in theory.

Will you agree if I just add the "int max_scan" argument and make it return a boolean
for the start? The caller will need to abort the for_each_process_thread() loop if
_continue() fails.


Probably this is not what we actually want for show_filter_state(), we can make it
better later. We can "embed" the rcu_lock_break() logic into _continue(), or change
break/continue to record the state (leader_start_time, thread_start_time) so that
a "false" return from _continue() means that the caller needs another schedule(),

	struct state state;

        rcu_read_lock();
        for_each_process_thread(p, t) {
                do_something_slow(p, t);

                if (SPENT_TOO_MANY_TIME) {
                        for_each_process_thread_break(p, t, &state);
        another_break:
                        rcu_read_unlock();
                        schedule();
                        rcu_read_lock();
                        if (!for_each_process_thread_continue(&p, &t, LIMIT, &state))
                        	goto another_break;
               	}
       	}
	rcu_read_unlock();

Not sure. I'd like to do something simple for the start. We need to make
show_state_filter() "preemptible" in any case. And even killable, I think.
Not only it can trivially trigger the soft-lockups (at least), it can simply
never finish.

Oleg.

  reply	other threads:[~2016-08-03 20:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25 16:23 [PATCH 0/3] introduce for_each_process_thread_{break,continue}() helpers Oleg Nesterov
2016-07-25 16:23 ` [PATCH 1/3] " Oleg Nesterov
2016-08-02 11:58   ` Peter Zijlstra
2016-08-03 20:26     ` Oleg Nesterov [this message]
2016-08-08 12:20       ` Peter Zijlstra
2016-07-25 16:23 ` [PATCH 2/3] hung_task.c: change rcu_lock_break() code to use for_each_process_thread_break/continue Oleg Nesterov
2016-07-25 16:23 ` [PATCH 3/3] hung_task.c: change the "max_count" " Oleg Nesterov
2016-07-26 18:57 ` [PATCH 0/1] (Was: introduce for_each_process_thread_{break,continue}() helpers) Oleg Nesterov
2016-07-26 18:57   ` [PATCH 1/1] stop_machine: touch_nmi_watchdog() after MULTI_STOP_PREPARE Oleg Nesterov
2016-07-27  8:06     ` Thomas Gleixner
2016-07-27 10:42     ` [tip:core/urgent] stop_machine: Touch_nmi_watchdog() " tip-bot for Oleg Nesterov

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=20160803202609.GA11419@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anderson@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=shuwang@redhat.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.