All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org, riel@redhat.com,
	tkhai@yandex.ru, mgorman@suse.de
Subject: Re: [PATCH] sched/fair: Care divide error in update_task_scan_period()
Date: Wed, 8 Oct 2014 10:31:39 +0200	[thread overview]
Message-ID: <20141008083139.GD10832@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <5434DCFF.1040208@jp.fujitsu.com>

On Wed, Oct 08, 2014 at 03:43:11PM +0900, Yasuaki Ishimatsu wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bfa3c86..fb7dc3f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1496,18 +1496,26 @@ static void update_task_scan_period(struct task_struct *p,
>  			slot = 1;
>  		diff = slot * period_slot;
>  	} else {
> -		diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
> +		if (unlikely((private + shared) == 0))
> +			/*
> +			 * This is a rare case. The trigger is node offline.
> +			 */
> +			diff = 0;
> +		else {
> +			diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
> 
> -		/*
> -		 * Scale scan rate increases based on sharing. There is an
> -		 * inverse relationship between the degree of sharing and
> -		 * the adjustment made to the scanning period. Broadly
> -		 * speaking the intent is that there is little point
> -		 * scanning faster if shared accesses dominate as it may
> -		 * simply bounce migrations uselessly
> -		 */
> -		ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private + shared));
> -		diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
> +			/*
> +			 * Scale scan rate increases based on sharing. There is
> +			 * an inverse relationship between the degree of sharing
> +			 * and the adjustment made to the scanning period.
> +			 * Broadly speaking the intent is that there is little
> +			 * point scanning faster if shared accesses dominate as
> +			 * it may simply bounce migrations uselessly
> +			 */
> +			ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS,
> +							(private + shared));
> +			diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
> +		}
>  	}
> 
>  	p->numa_scan_period = clamp(p->numa_scan_period + diff,

Yeah, so I don't like the patch nor do I really like the function as it
stands -- which I suppose is part of why I don't like the patch.

The problem I have with the function is that its very inconsistent in
behaviour. In the early return path it sets numa_scan_period and
numa_next_scan, in the later return path it sets numa_scan_period and
numa_faults_locality.

I feel both return paths should affect the same set of variables, esp.
the non clearing of numa_faults_locality in the early path seems weird.

The thing I suppose I don't like about the patch is its added
indentation and the fact that the simple +1 thing wasn't considered.

  reply	other threads:[~2014-10-08  8:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08  6:43 [PATCH] sched/fair: Care divide error in update_task_scan_period() Yasuaki Ishimatsu
2014-10-08  8:31 ` Peter Zijlstra [this message]
2014-10-08 11:51 ` Wanpeng Li
2014-10-09  5:34   ` Yasuaki Ishimatsu
2014-10-08 16:42 ` Rik van Riel
2014-10-08 16:54   ` Peter Zijlstra
2014-10-09  5:19     ` Yasuaki Ishimatsu

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=20141008083139.GD10832@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=riel@redhat.com \
    --cc=tkhai@yandex.ru \
    /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.