lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130628100723.GC8362@linux.vnet.ibm.com>
Date:	Fri, 28 Jun 2013 15:37:23 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Mel Gorman <mgorman@...e.de>, Ingo Molnar <mingo@...nel.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/8] sched: Favour moving tasks towards the preferred node

> > > +
> > > +
> > >  /*
> > >   * can_migrate_task - may task p from runqueue rq be migrated to this_cpu?
> > >   */
> > > @@ -3945,10 +3977,14 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env)
> > >  
> > >  	/*
> > >  	 * Aggressive migration if:
> > > -	 * 1) task is cache cold, or
> > > -	 * 2) too many balance attempts have failed.
> > > +	 * 1) destination numa is preferred
> > > +	 * 2) task is cache cold, or
> > > +	 * 3) too many balance attempts have failed.
> > >  	 */
> > >  
> > > +	if (migrate_improves_locality(p, env))
> > > +		return 1;
> > 
> > Shouldnt this be under tsk_cache_hot check?
> > 
> > If the task is cache hot, then we would have to update the corresponding  schedstat
> > metrics.
> 
> No; you want migrate_degrades_locality() to be like task_hot(). You want
> to _always_ migrate tasks towards better locality irrespective of local
> cache hotness.
> 

Yes, I understand that numa should have more priority over cache.
But the schedstats will not be updated about whether the task was hot or
cold.

So lets say the task was cache hot but numa wants it to move, then we
should certainly move it but we should update the schedstats to mention that we
moved a cache hot task.

Something akin to this.

	tsk_cache_hot = task_hot(p, env->src_rq->clock_task, env->sd);
	if (tsk_cache_hot) {
		if (migrate_improves_locality(p, env) || 
		 	(env->sd->nr_balance_failed > env->sd->cache_nice_tries)) {
#ifdef CONFIG_SCHEDSTATS
			schedstat_inc(env->sd, lb_hot_gained[env->idle]);
			schedstat_inc(p, se.statistics.nr_forced_migrations);
#endif
			return 1;
		}
		schedstat_inc(p, se.statistics.nr_failed_migrations_hot);
		return 0;
	}
	return 1;

-- 
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ