linux-kernel - Re: [PATCH v2 18/19] sched/numa: Reset scan rate whenever task moves across nodes

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]

Date:   Wed, 4 Jul 2018 04:19:13 -0700
From:   Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:     Mel Gorman <mgorman@...hsingularity.net>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Rik van Riel <riel@...riel.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 18/19] sched/numa: Reset scan rate whenever task moves
 across nodes

> We talked about this before but I would at least suggest that you not
> reset the scan if moving to the preferred node or if the node movement
> has nothing to do with the preferred nid. e.g.
> 

I understand your concern and okay to drop this patch for now.
I will try to rework and come back later.

> 	/*
> 	 * Ignore if the migration is not changing node, if it is migrating to
> 	 * the preferred node or moving between two nodes that are not preferred
> 	 */
> 
> 	if (p->numa_faults) {
> 		int src_nid = cpu_to_node(task_cpu(p));
> 		int dst_nid = cpu_to_node(new_cpu);
> 
> 		if (src_nid == dst_nid || dst_nid == p->numa_preferred_nid ||
> 		    (p->numa_preferred_nid != -1 && src_nid != p->numa_preferred_nid))

With out this change/patch, we used to reduce our scan rate whenever numa
balancer moved a task to a preferred node. This was made to verify that
the task movement was correct. The check ( dst_nid == p->numa_preferred_nid)
will negate that verification. I thought the whole point of reducing the
scan period was to correct if we choose a wrong node.

> 			return;
> 
> 		p->numa_scan_period = task_scan_start(p);
> 
> Note too that the next scan can be an arbitrary amount of time in the
> future. Consider as an alternative to schedule an immediate scan instead
> of adjusting the rate with
> 
> 		p->mm->numa_next_scan = jiffies;
> 

I will try to work along these lines.  Though the scan happens
immediately the task placement will not happen immediately so I am not
sure if it would help much.

> That might be less harmful in terms of overhead while still collecting
> some data in the short-term.
> 

-- 
Thanks and Regards
Srikar