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

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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