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: <20121022075857.GA2198@suse.de>
Date:	Mon, 22 Oct 2012 08:58:57 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, torvalds@...ux-foundation.org,
	hannes@...xchg.org, akpm@...ux-foundation.org, tglx@...utronix.de
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:numa/core] sched/numa/mm: Improve migration

On Thu, Oct 18, 2012 at 10:05:39AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  713f937655c4b15131b5a0eae4610918a4febe17
> Gitweb:     http://git.kernel.org/tip/713f937655c4b15131b5a0eae4610918a4febe17
> Author:     Peter Zijlstra <a.p.zijlstra@...llo.nl>
> AuthorDate: Fri, 12 Oct 2012 19:30:14 +0200
> Committer:  Ingo Molnar <mingo@...nel.org>
> CommitDate: Mon, 15 Oct 2012 14:18:40 +0200
> 
> sched/numa/mm: Improve migration
> 
> Add THP migration. Extend task_numa_fault() to absorb THP faults.
> 
> [ Would be nice if the gents on Cc: expressed their opinion about
>   this change. A missing detail might be cgroup page accounting,
>   plus the fact that some architectures might cache PMD_NONE pmds
>   in their TLBs, needing some extra TLB magic beyond what we already
>   do here? ]
> 

I'm travelling for a conference at the moment so will not get the chance
to properly review this until I get back. Is there any plan to post the
schednuma patches to linux-mm so the full series can be reviewed? I can
extract the patches from -tip when I get back but it's still less than
ideal from a review standpoint.

Superficially, the patch looks ok but as I lack context on what the
rest of schednuma looks like I cannot be sure so I'm not going to ack
it. Basically this is very similar to __unmap_and_move except it doesn't
deal with migration PTEs -- presumably because the PTE is PROT_NONE so it
gets queued up behind it. There is a downside of that. With migration PTEs,
faults during migration will wait on the PTE. With this approach, I think
multiple faults will alloc a hugepage, realise the ptes are no longer the
same and back off. It should still work but it's potentially more expensive.
Was that considered? Is it deliberate? If so, why?

It also feels like the migration part should have been a helper function
called unmap_and_move_thp() in migrate.c instead of being buried in
mm/huge_memory.c

-- 
Mel Gorman
SUSE Labs
--
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