All of lore.kernel.org
 help / color / mirror / Atom feed
From: luca abeni <luca.abeni@santannapisa.it>
To: Juri Lelli <juri.lelli@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Claudio Scordino <claudio@evidence.eu.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tommaso Cucinotta <tommaso.cucinotta@sssup.it>,
	Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [RFC v4 2/6] sched/deadline: improve the tracking of active utilization
Date: Wed, 11 Jan 2017 22:22:59 +0100	[thread overview]
Message-ID: <20170111222259.5337f935@sweethome> (raw)
In-Reply-To: <20170111170542.GL10415@e106622-lin>

On Wed, 11 Jan 2017 17:05:42 +0000
Juri Lelli <juri.lelli@arm.com> wrote:

> Hi,
> 
> On 30/12/16 12:33, Luca Abeni wrote:
> > From: Luca Abeni <luca.abeni@unitn.it>
> > 
> > This patch implements a more theoretically sound algorithm for
> > tracking active utilization: instead of decreasing it when a
> > task blocks, use a timer (the "inactive timer", named after the
> > "Inactive" task state of the GRUB algorithm) to decrease the
> > active utilization at the so called "0-lag time".
> > 
> > Signed-off-by: Luca Abeni <luca.abeni@unitn.it>
> > ---  
> 
> [...]
> 
> > +static enum hrtimer_restart inactive_task_timer(struct hrtimer
> > *timer) +{
> > +	struct sched_dl_entity *dl_se = container_of(timer,
> > +						     struct
> > sched_dl_entity,
> > +
> > inactive_timer);
> > +	struct task_struct *p = dl_task_of(dl_se);
> > +	struct rq_flags rf;
> > +	struct rq *rq;
> > +
> > +	rq = task_rq_lock(p, &rf);
> > +
> > +	if (!dl_task(p) || p->state == TASK_DEAD) {
> > +		if (p->state == TASK_DEAD &&
> > dl_se->dl_non_contending)
> > +			sub_running_bw(&p->dl,
> > dl_rq_of_se(&p->dl)); +
> > +		__dl_clear_params(p);
> > +
> > +		goto unlock;
> > +	}
> > +	if (dl_se->dl_non_contending == 0)
> > +		goto unlock;
> > +
> > +	sched_clock_tick();
> > +	update_rq_clock(rq);
> > +
> > +	sub_running_bw(dl_se, &rq->dl);
> > +	dl_se->dl_non_contending = 0;
> > +unlock:
> > +	task_rq_unlock(rq, p, &rf);
> > +	put_task_struct(p);
> > +
> > +	return HRTIMER_NORESTART;
> > +}
> > +  
> 
> [...]
> 
> >  static void inc_dl_deadline(struct dl_rq *dl_rq, u64 deadline)
> > @@ -934,7 +1014,28 @@ enqueue_dl_entity(struct sched_dl_entity
> > *dl_se, if (flags & ENQUEUE_WAKEUP) {
> >  		struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
> >  
> > -		add_running_bw(dl_se, dl_rq);
> > +		if (dl_se->dl_non_contending) {
> > +			/*
> > +			 * If the timer handler is currently
> > running and the
> > +			 * timer cannot be cancelled,
> > inactive_task_timer()
> > +			 * will see that dl_not_contending is not
> > set, and
> > +			 * will do nothing, so we are still safe.  
> 
> Here and below: the timer callback will actually put_task_struct()
> (see above) if dl_not_contending is not set; that's why we don't need
> to do that if try_to_cancel returned -1 (or 0). Saying "will do
> nothing" is a bit misleading, IMHO.

Sorry... I originally had a bug with this put_task_struct() thing. The
bug is now (hopefully :) fixed, but I forgot to update the comment...
I'll fix it for next submission.

> > @@ -1097,6 +1198,22 @@ select_task_rq_dl(struct task_struct *p, int
> > cpu, int sd_flag, int flags) }
> >  	rcu_read_unlock();
> >  
> > +	rq = task_rq(p);
> > +	raw_spin_lock(&rq->lock);
> > +	if (p->dl.dl_non_contending) {
> > +		sub_running_bw(&p->dl, &rq->dl);
> > +		p->dl.dl_non_contending = 0;
> > +		/*
> > +		 * If the timer handler is currently running and
> > the
> > +		 * timer cannot be cancelled, inactive_task_timer()
> > +		 * will see that dl_not_contending is not set, and
> > +		 * will do nothing, so we are still safe.
> > +		 */
> > +		if (hrtimer_try_to_cancel(&p->dl.inactive_timer)
> > == 1)
> > +			put_task_struct(p);
> > +	}
> > +	raw_spin_unlock(&rq->lock);
> > +
> >  out:
> >  	return cpu;
> >  }  
> 
> We already raised the issue about having to lock the rq in
> select_task_rq_dl() while reviewing the previous version; did you have
> any thinking about possible solutions? Maybe simply bail out (need to
> see how frequent this is however) or use an inner lock?

Sorry; I did not come up with any good idea for avoiding to lock the
rq... I'll think about this again... The only alternative idea I have
is just to avoid changing cpu, but I do not know if it is acceptable...




			Thanks,
				Luca

  reply	other threads:[~2017-01-11 21:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-30 11:33 [RFC v4 0/6] CPU reclaiming for SCHED_DEADLINE Luca Abeni
2016-12-30 11:33 ` [RFC v4 1/6] sched/deadline: track the active utilization Luca Abeni
2016-12-30 11:33 ` [RFC v4 2/6] sched/deadline: improve the tracking of " Luca Abeni
2017-01-11 17:05   ` Juri Lelli
2017-01-11 21:22     ` luca abeni [this message]
2016-12-30 11:33 ` [RFC v4 3/6] sched/deadline: fix the update of the total -deadline utilization Luca Abeni
2016-12-30 11:33 ` [RFC v4 4/6] sched/deadline: implement GRUB accounting Luca Abeni
2016-12-30 11:33 ` [RFC v4 5/6] sched/deadline: do not reclaim the whole CPU bandwidth Luca Abeni
2016-12-30 11:33 ` [RFC v4 6/6] sched/deadline: make GRUB a task's flag Luca Abeni
2017-01-03 18:58 ` [RFC v4 0/6] CPU reclaiming for SCHED_DEADLINE Daniel Bristot de Oliveira
2017-01-03 21:33   ` luca abeni
2017-01-04 12:17   ` luca abeni
2017-01-04 15:14     ` Daniel Bristot de Oliveira
2017-01-04 16:42       ` Luca Abeni
2017-01-04 18:00         ` Daniel Bristot de Oliveira
2017-01-04 18:30           ` Luca Abeni
2017-01-11 12:19             ` Juri Lelli
2017-01-11 12:39               ` Luca Abeni
2017-01-11 15:06                 ` Juri Lelli
2017-01-11 21:16                   ` luca abeni

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=20170111222259.5337f935@sweethome \
    --to=luca.abeni@santannapisa.it \
    --cc=bristot@redhat.com \
    --cc=claudio@evidence.eu.com \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tommaso.cucinotta@sssup.it \
    /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.