linux-kernel - Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

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, 19 Aug 2015 09:41:13 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Mike Galbraith <umgwanakikbuti@...il.com>
Cc:	Paul Turner <pjt@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>, lizefan@...wei.com,
	cgroups <cgroups@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	kernel-team <kernel-team@...com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 3/3] sched: Implement interface for cgroup unified
 hierarchy

Hello, Mike.

On Wed, Aug 19, 2015 at 05:23:40AM +0200, Mike Galbraith wrote:
> Hm.  I know of a big data outfit to which attach/detach performance was
> important enough for them to have plucked an old experimental overhead
> reduction hack (mine) off lkml, and shipped it.  It must have mattered a
> LOT for them (not suicidal crash test dummies) to have done that.

There haven't been any guidelines on cgroup usage.  Of course people
have been developing in all directions.  It's a natural learning
process and there are use cases which can be served by migrating
processes back and forth.  Nobody is trying to prevent that; however,
if one examines how resources and their associations need to be
tracked for accounting and control, it's evident that there are
inherent trade-offs between migration and the stuff which happens
while not migrating and it's clear which side is more important.

Most problems can be solved in different ways and I'm doubtful that
e.g. bouncing jobs to worker threads would be more expensive than
migrating the worker back and forth in a lot of cases.  If migrating
threads around floats somebody's boat, that's fine but that has never
been and can't be the focus of design and optimization, not at the
cost of the actual hot paths.

Thanks.

-- 
tejun
--
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/