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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Aug 2015 00:52:32 -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

Hey, Mike.

On Thu, Aug 20, 2015 at 06:00:59AM +0200, Mike Galbraith wrote:
> If create/attach/detach/destroy aren't hot paths, what is?  Those are
> fork/exec/exit cgroup analogs.  If you have thousands upon thousands of

Things like page faults?  cgroup controllers hook into subsystems and
their hot path operations get affected by the method of cgroup
association.

Also, migration and create/destroy are completely different.
create/destroy don't need much synchronization - a new task is made
visible only after the initial association is set up and a dying
task's association is destroyed only after the task isn't referenced
by anybody.  There's nothing dynamic about those compared to
migration.

> potentially active cgroups (aka customers), you wouldn't want to keep
> them all around just in case when you can launch cgroup tasks the same
> way we launch any other task.  You wouldn't contemplate slowing down
> fork/exec/exit, but create/attach/detach/destroy are one and the same..
> they need to be just as fast/light as they can be, as they are part and
> parcel of the higher level process.

You're conflating two completely different operations.  Also, when I
say migration is a relatively expensive operation, I'm comparing it to
bouncing a request to another thread as opposed to bouncing the
issuing thread to different cgroup request-by-request.

> That's why my hack ended up in a large enterprise outfit's product, it
> was _needed_ to fix up cgroups performance suckage.  That suckage was
> fixed up properly quite a bit later.

Hmm... I bet you're talking about the removal of synchronize_rcu() in
migration path, sure, that was a silly thing to have there but also
that comparison is likely a couple orders of magnitude off of what the
thread was originally talking about.

> Anyway, if what they or anybody like them can currently do with their
> job launcher/manager gizmos is negatively impacted, they can gripe for
> themselves.  All I'm saying is that there are definitely users out there
> to whom create/attach/detach/destroy are highly important.

Hmmm... I think this discussion got pretty badly derailed at this
point.  If I'm not mistaken, you're talking about tens or a few
hundred millisecs of latency per migration which no longer exists and
won't ever come back and the discussion originally was about something
like migrating thread for issuing several IO requests versus bouncing
that to a dedicated issuer thread in that domain.

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/