Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1255040 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-24 00:30 +0200
    Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-24 06:40 +0200
      Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-25 03:20 +0100
        Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-25 04:50 +0100
          Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-27 04:20 +0100
            Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-27 06:50 +0100
              Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-27 06:50 +0100
                Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-27 07:00 +0100
                  Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-27 07:10 +0100
                    Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-27 07:10 +0100
        Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Linus Torvalds <torvalds@linux-foundation.org> - 2015-10-25 05:00 +0100
          Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Ingo Molnar <mingo@kernel.org> - 2015-10-25 10:40 +0100
            Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Theodore Ts'o <tytso@mit.edu> - 2015-10-25 11:50 +0100
              Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Florian Weimer <fweimer@redhat.com> - 2015-10-25 11:50 +0100
                Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Theodore Ts'o <tytso@mit.edu> - 2015-10-25 13:00 +0100
                  Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Florian Weimer <fweimer@redhat.com> - 2015-10-25 14:20 +0100
                    Getrandom wrapper Theodore Ts'o <tytso@mit.edu> - 2015-10-25 14:50 +0100
                      Re: Getrandom wrapper Florian Weimer <fweimer@redhat.com> - 2015-10-26 14:40 +0100
                    Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Peter Zijlstra <peterz@infradead.org> - 2015-10-26 15:20 +0100

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

Hello, Paul.

On Thu, Oct 15, 2015 at 04:42:37AM -0700, Paul Turner wrote:
> > The thing which bothers me the most is that cpuset behavior is
> > different from global case for no good reason.
> 
> I've tried to explain above that I believe there are reasonable
> reasons for it working the way it does from an interface perspective.
> I do not think they can be so quickly discarded out of hand.  However,
> I think we should continue winnowing focus and first resolve the model
> of interaction for sub-process hierarchies,

One way or the other, I think the kernel needs to sort out how task
affinity masks are handled when the available CPUs change, be that
from CPU hotplug or cpuset config changes.

On forcing all affinity masks to the set of available CPUs, I'm still
not convinced that it's a useful extra behavior to implement for
cpuset especially given that the same can be achieved from userland
without too much difficulty.  This goes back to the argument for
implmenting the minimal set of functionality which can be used as
building blocks.  Updating all task affinty masks is an irreversible
destructive operation.  It doesn't enable anything which can't be
otherwise but does end up restricting how the feature can be used.

But yeah, let's shelve this subject for now.

> > Now, if you make the in-process grouping dynamic and accessible to
> > external entities (and if we aren't gonna do that, why even bother?),
> > this breaks down and we have some of the same problems we have with
> > allowing applications to directly manipulate cgroup sub-directories.
> > This is a fundamental problem.  Setting attributes can be shared but
> > organization is an exclusive process.  You can't share that without
> > close coordination.
> 
> Your concern here is centered on permissions, not the interface.
> 
> This seems directly remedied by exactly:
>   Any sub-process hierarchy we exposed would be locked down in terms
> of write access.  These would not be generally writable.  You're
> absolutely correct that you can't share without close coordination,
> and granting the appropriate permissions is part of that.

It is not about permissions.  It is about designing an interface which
guarantees certain set of invariants regardless of priviledges - even
root can't violate such invariants short of injecting code into and
modifying the behavior of the target process.  This isn't anything
unusual.  In fact, permission based access control is something which
is added if and only if allowing and controlling accesses from
multiple parties is necessary and needs to be explicitly justified.

If coordination in terms of thread hierarchy organization from the
target process is needed for allowing external entities to twiddle
with resource distribution, no capability is lost by making the
organization solely the responsibility of the target process while
gaining a lot stronger set of behavioral invariants.  I can't see
strong enough justifications for allowing external entities to
manipulate in-process thread organization.

> > assigning the full responsiblity of in-process organization to the
> > application itself and tying it to static parental relationship allows
> > for solid common grounds where these resource operations can be
> > performed by different entities without causing structural issues just
> > like other similar operations.
> 
> But cases have already been presented above where the full
> responsibility cannot be delegated to the application.  Because we
> explicitly depend on constraints being provided by the external
> environment.

I don't think such cases have been presented.  The only thing
necessary is the target processes organizing threads in a way which
allows external agents to apply external constraints.

> > It's not that but more about what the file-system interface implies.
> > It's not just different.  It breaks a lot of expectations a lot of
> > application visible kernel interface provides as explained above.
> > There are reasons why we usually don't do things this way.
> 
> The arguments you've made above are largely centered on permissions
> and the right to make modifications.  I don't see what other
> expectations you believe are being broken here.  This still feels like
> an aesthetic objection.

I hope my points are clear by now.

> > It does require the applications to follow certain protocols to
> > organize itself but this is a pretty trivial thing to do and comes
> > with the benefit that we don't need to introduce a completely new
> > grouping concept to applications.
> 
> I strongly disagree here:  Applications today do _not_ use sub-process
> clone hierarchies today.  As a result, this _is_ introducing a
> completely new grouping concept because it's one applications have
> never cared about outside of a shell implementation.

It is a logical extension of how the kernel organizes processes in the
system.  It's a lot more native to how programs usually interact with
the system than meddling with a pseudo file system.

> > That should be like a two hour job for most applications.  This is a
> > trivial thing to do.  It's difficult for me to consider the difficulty
> > of doing this a major decision point.
> 
> You are seriously underestimating the complexity and API overhead this
> introduces.  It cannot be claimed trivial and discarded; it's not.

You're exaggerating.  Requiring applications to organize threads
according to, most likely, their logical roles, is not an unreasonable
burden for enabling hierarchical resource control.  While I can
understand the reluctance for users who are currently making use of
task-granular cgroups, please realize that we're trying to introduce a
whole new class of features directly visible to applications.  Future
usages will vastly outnumber that of the current cgroup hack.  In
addition, it's not like the current users are required to migrate
immediately.

> "- If $TID isn't already a resource group leader, it creates a
>   sub-cgroup, sets $KEY to $VAL and moves $PID and all its descendants
>   to it.
> 
> - If $TID is already a resource group leader, set $KEY to $VAL."
> 
> This only allows resource groups at the root level to be created.
> There is no way to make $TID2 a resource group leader, parented by
> $TID1.

I probably should have written it better but obviously a new resource
group for $TID would be nested under the resource group $TID is
already in.

> > We already have those tids.
> 
> External management applications do not.  This was covering that would
> now need a new API to handle their publishing.  Whereas using the VFS
> handles this naturally.

I suppose you're suggesting that naming conventions in the per-process
cgroup hierarchy can be used as a mechanism to carry such information,
am I right?  If so, it's trivial to solve.  Just let the application
tag the TID based resource groups with an integer or string
identifying hints.

> > I see but you can easily do that the other way too, right?  Let the
> > applications publish where they put their threads and let the external
> > entity set configs on them.
> 
> And what API controls the right to do this?

Exactly the same as prlimit(2)?  In fact, while details will dictate
what will happen exactly, we might even just extend prlimit(2) instead
of introducing completely new syscalls.  Please not that the fact that
prlimit(2) can be so easily referred to is not an accident.  This is
because what's being proposed is a natural extension of the model the
kernel already uses.

> > Not everything.  Just the ones which make sense in-process.  This is
> > exactly the process we need to go through when introducing new
> > syscalls.  Why is this a surprise?  We want to scrutinize them, hard.
> 
> I'm talking only about the control->$KEY mapping.  Yes it would be a
> subset, but this seems a large step back in usability.

I don't understand.  This is introducing a whole new set of syscalls
to be used by applications and we *need* to scrutinize and restrict
what's being exposed.  Furthermore, as there are inherent differences
in system management interface and application programming interface,
we should filter what's to be exposed to individual applications
regardless of the specific mechanism for the interface.  For example,
it doesn't make any sense to expose "cgroup.procs" or "release_agent"
on in-process interface.

It'd be a step back in usability only for users who have been using
cgroups in fringing ways which can't be justified for ratification and
we do want to actively filter those out.  It may cause a short-term
pain for some but the whole thing is an a lot larger problem.  Let's
please think long term.

> > I'm not following.  Why would it need to do that already?
> 
> Because the process-level interface will continue to work the way it
> does today.  That means we still need to implement these operations.
> 
> This same library code could be shared for applications to use on
> their private, sub-process, controls.

This doesn't make any sense.  The reason why cgroup users need low
level access libraries is because the file system interface is too
unwiedly to program directly against.  The fact the system management
interface requires such library can't possibly be an argument against
the kernel providing a programmable interface to applications.

> > This is like saying syscalls are worse in terms of progammability
> > compared to opening and writing formatted strings for setting
> > attributes.  If that's what you're saying, let's just agree to disgree
> > on this one.
> 
> The goal of such a system is as much administration as it is a
> programmable interface.  There's a reason much configuration is
> specified by sysctls and not syscalls.

And there are reasons why individual applications usually don't
program directly against sysctl or other system management interfaces.
It's the kernel's job to provide abstractions so that those two
spheres can be separated reasonably.  We don't want system management
meddling with thread organization of applications.  That's the
application's domain.  Applying attributes on top sure can be done
from outside.

> > That's comparing apples and oranges.  Threads being moved around and
> > hierarchies changing beneath them present a whole different issues
> > than someone else setting an attribute to a different value.  The
> > operations might fail, might set properties on the wrong group.
> 
> There are no differences between using VFS and your proposed API for this.

I hope this part is clear now.

> I think you misunderstood here.  What I'm saying is equivalently:
> - How do I bless a 'good' external agent to be allowed to make modificaitons
> - How do I make sure a malicious external process is not able to make
> modifications

I'm lost why these are even being asked.  Why would it be any
different from other syscalls which manipulate similar attributes?

> > How is that different?  Sure, the name is created by the threads but
> > once you set the resource, the tid would be the resource group ID and
> > the thread can go away.  It's still an object named by an ID.
> 
> Huh?? If the thread goes away, then the tid can be re-used -- within
> the same process.  Now you have non-unique IDs to operate on??

The TID can be pinned on group creation or we can track thread
hierarchy (while collapsing irrelevant dead parts) to allow setting
attributes on siblings instead.  These are details which can be
fleshed out as design and implementation progresses.  Let's please
concentrate on the general approach for now.

> > It allows for structural inconsistencies where applications can end up
> > performing operations which are non-sensical.  Breaking that invariant
> > is substantial.  Why would we do that if
> 
> Can you please provide an example?  I don't know what inconsistencies
> you mean here.  In particular, I do not see anything that your
> proposed interface resolves versus this; while being _significantly_
> simpler for applications to use and implement.

The fact that in-process hierarchy can be manipulated by external
entities, regardless of permissions, means that the organization can
be changed underneath the application in a way which can cause various
failures and unexpected behaviors when the application later on
performs operations assuming the original organization.

> > Can we at least agree that we're now venturing into an area where
> > things aren't really critical?  The core functionality here is being
> > able to hierarchically categorize threads and assign resource limits
> > to them.  Can we agree that the minimum core functionality is met in
> > both approaches?
> 
> I'm not sure entirely how to respond here.  I am deeply concerned that
> the API you're proposing is not tenable for providing this core
> functionality.  I worry that you're introducing serious new challenges
> and too quickly discarding them as manageable.

The capability to obtain here is allowing threads of a process to be
organized hierarchically and controlling resource distribution along
that hierarchy.  I'm asking whether you agree that such core
capability can be obtained in both approaches.

I think you're underestimating the gravity of adding a whole new set
of interfaces to be used by applications.  This is something which
will be with us decades later.  I can understand the reluctance coming
for the existing users; however, in perspective, that is not a concern
that we can or should hinge major decisions on, so I beg you to take a
step back from immediate concerns and take a longer-term look at the
problem.

Also, while holding off the v2 interface for the cpu controller is an
understandable method of exerting political (I don't mean in a
derogative way) pressure on resolving the in-process resource
management issue, I don't think our specific disagreements affect
system level interface in any way.  Given the size of the problem,
implementing a proper solution for this problem will likely take quite
a while even after we agree on the approach.  As, AFAICS, there aren't
technical reasons to hold back v2 interface, can we please proceed
there?  I promise to keep working on in-process resource distribution
to the best of my abilities.  It's something I want to solve anyway.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1255129

On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote:

> It'd be a step back in usability only for users who have been using
> cgroups in fringing ways which can't be justified for ratification and
> we do want to actively filter those out.

Of all the cgroup signal currently in existence, seems the Google signal
has to have the most volume under the curve by a mile.  If you were to
filter that signal out, what remained would be a flat line of noise.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255266

Hello, Mike.

On Sat, Oct 24, 2015 at 06:36:07AM +0200, Mike Galbraith wrote:
> On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote:
> 
> > It'd be a step back in usability only for users who have been using
> > cgroups in fringing ways which can't be justified for ratification and
> > we do want to actively filter those out.
> 
> Of all the cgroup signal currently in existence, seems the Google signal
> has to have the most volume under the curve by a mile.  If you were to
> filter that signal out, what remained would be a flat line of noise.

This is a weird direction to take the discussion, but let me provide a
counter argument.

Google sure is an important user of the kernel and likely the most
extensive user of cgroup.  At the same time, its kernel efforts are
largely in service of a few very big internal customers which are in
control of large part of the entire software stack.  The things that
are important for general audience of the kernel in the long term
don't necessarily coincide with what such efforts need or want.

I'd even venture to say as much as the inputs coming out of google are
interesting and important, they're also a lot more prone to lock-in
effects to short term solutions and status-quo given their priorities.
This is not to denigrate google's kernel efforts but just to
counter-balance "it's google" as a shortcut for proper technical
discussions.

There are good reasons why cgroup is the design disaster as it is now
and chasing each usage scenario and hack which provides the least
immediate resistance without paying the effort to extract the actual
requirements and common solutions is an important one.  It is critical
to provide back-pressure for long-term thinking and solutions;
otherwise, we're bound to repeat the errors and end up with something
which everyone loves to hate.

We definitely need to weigh the inputs from heavy users but also need
to discern the actual problems which need to be solved from the
specific mechanisms chosen to solve them.  Let's please keep the
discussions technical.  That's the best way to reach a viable
long-term solution which can benefit a lot wider audience in the long
term.  Even though that might not be the path of least immediate
resistance, I believe that google will be an eventual beneficiary too.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255274

On Sun, 2015-10-25 at 11:18 +0900, Tejun Heo wrote:
> Hello, Mike.
> 
> On Sat, Oct 24, 2015 at 06:36:07AM +0200, Mike Galbraith wrote:
> > On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote:
> > 
> > > It'd be a step back in usability only for users who have been using
> > > cgroups in fringing ways which can't be justified for ratification and
> > > we do want to actively filter those out.
> > 
> > Of all the cgroup signal currently in existence, seems the Google signal
> > has to have the most volume under the curve by a mile.  If you were to
> > filter that signal out, what remained would be a flat line of noise.
> 
> This is a weird direction to take the discussion, but let me provide a
> counter argument.

I don't think it's weird, it's just a thought wrt where pigeon holing
could lead:  If you filter out current users who do so in a manner you
consider to be in some way odd, when all the filtering is done, you may
find that you've filtered out the vast majority of current deployment.

> Google sure is an important user of the kernel and likely the most
> extensive user of cgroup.  At the same time, its kernel efforts are
> largely in service of a few very big internal customers which are in
> control of large part of the entire software stack.  The things that
> are important for general audience of the kernel in the long term
> don't necessarily coincide with what such efforts need or want.

I'm not at all sure of this, but I suspect that SUSE's gigabuck size
cgroup power user will land in the same "fringe" pigeon hole.  If so,
that would be another sizeable dent in volume.

My point is that these power users likely _are_ your general audience.
 
> I'd even venture to say as much as the inputs coming out of google are
> interesting and important, they're also a lot more prone to lock-in
> effects to short term solutions and status-quo given their priorities.
> This is not to denigrate google's kernel efforts but just to
> counter-balance "it's google" as a shortcut for proper technical
> discussions.
> 
> There are good reasons why cgroup is the design disaster as it is now
> and chasing each usage scenario and hack which provides the least
> immediate resistance without paying the effort to extract the actual
> requirements and common solutions is an important one.  It is critical
> to provide back-pressure for long-term thinking and solutions;
> otherwise, we're bound to repeat the errors and end up with something
> which everyone loves to hate.
> 
> We definitely need to weigh the inputs from heavy users but also need
> to discern the actual problems which need to be solved from the
> specific mechanisms chosen to solve them.  Let's please keep the
> discussions technical.

Sure, it was just a thought wrt "actively filter those out" and who all
"those" may end up being.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256439

Hello, Mike.

On Sun, Oct 25, 2015 at 04:43:33AM +0100, Mike Galbraith wrote:
> I don't think it's weird, it's just a thought wrt where pigeon holing
> could lead:  If you filter out current users who do so in a manner you
> consider to be in some way odd, when all the filtering is done, you may
> find that you've filtered out the vast majority of current deployment.

I think you misunderstood what I wrote.  It's not about excluding
existing odd use cases.  It's about examining the usages and
extracting the required capabilities and building an interface which
is well defined and blends well with the rest of programming interface
provided by the kernel so that those can be achieved in a saner way.

If doing acrobatics with the current interface is necessary to acheive
certain capabilities, we need to come up with a better interface for
those.  If fringe usages can be satisfied using better constructs, we
should implement that and encourage transition to a better mechanism.

> I'm not at all sure of this, but I suspect that SUSE's gigabuck size
> cgroup power user will land in the same "fringe" pigeon hole.  If so,
> that would be another sizeable dent in volume.
> 
> My point is that these power users likely _are_ your general audience.

Sure, that doesn't mean we shouldn't scrutinize the interface we
implement to support those users.  Also, cgroup also definitely had
some negative spiral effect where eccentric mechanisms and interfaces
discouraged general wider usages fortifying the argument that "we're
the main users" which in turn fed back to even weirder things being
added.  Everybody including the "heavy" users suffers from such
failures in the long term.

We sure want to support all the valid use cases from heavy users in a
reasonable way but that doesn't mean we say yes to everything.

> Sure, it was just a thought wrt "actively filter those out" and who all
> "those" may end up being.

I hope what I meant is clearer now.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256474

On Tue, 2015-10-27 at 12:16 +0900, Tejun Heo wrote:
> Hello, Mike.
> 
> On Sun, Oct 25, 2015 at 04:43:33AM +0100, Mike Galbraith wrote:
> > I don't think it's weird, it's just a thought wrt where pigeon holing
> > could lead:  If you filter out current users who do so in a manner you
> > consider to be in some way odd, when all the filtering is done, you may
> > find that you've filtered out the vast majority of current deployment.
> 
> I think you misunderstood what I wrote.  It's not about excluding
> existing odd use cases.  It's about examining the usages and
> extracting the required capabilities and building an interface which
> is well defined and blends well with the rest of programming interface
> provided by the kernel so that those can be achieved in a saner way.

Sure, sounds fine, I just fervently hope that the below is foul swamp
gas having nothing what so ever to do with your definition of "saner".

http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign

http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

I'm not into begging.  I really don't want to have to ask anyone to
pretty please do for me what I can currently do all by my little self
without having to give a rats ass less whether what I want to do fits in
the world view of this or that obnoxious little control freak.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256475

Hello,

On Tue, Oct 27, 2015 at 06:42:11AM +0100, Mike Galbraith wrote:
> Sure, sounds fine, I just fervently hope that the below is foul swamp
> gas having nothing what so ever to do with your definition of "saner".

lol, idk, you keep taking things in weird directions.  Let's just stay
technical, okay?

> http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
> 
> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> 
> I'm not into begging.  I really don't want to have to ask anyone to
> pretty please do for me what I can currently do all by my little self
> without having to give a rats ass less whether what I want to do fits in
> the world view of this or that obnoxious little control freak.

Well, if you think certain things are being missed, please speak up.
Not in some media campaign way but with technical reasoning and
justifications.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256476

On Tue, 2015-10-27 at 14:46 +0900, Tejun Heo wrote:
> Hello,
> 
> On Tue, Oct 27, 2015 at 06:42:11AM +0100, Mike Galbraith wrote:
> > Sure, sounds fine, I just fervently hope that the below is foul swamp
> > gas having nothing what so ever to do with your definition of "saner".
> 
> lol, idk, you keep taking things in weird directions.  Let's just stay
> technical, okay?
> 
> > http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
> > 
> > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> > 
> > I'm not into begging.  I really don't want to have to ask anyone to
> > pretty please do for me what I can currently do all by my little self
> > without having to give a rats ass less whether what I want to do fits in
> > the world view of this or that obnoxious little control freak.
> 
> Well, if you think certain things are being missed, please speak up.
> Not in some media campaign way but with technical reasoning and
> justifications.

Inserting a middle-man is extremely unlikely to improve performance.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256481

On Tue, Oct 27, 2015 at 06:56:42AM +0100, Mike Galbraith wrote:
> > Well, if you think certain things are being missed, please speak up.
> > Not in some media campaign way but with technical reasoning and
> > justifications.
> 
> Inserting a middle-man is extremely unlikely to improve performance.

I'm not following you at all.  Technical reasoning and justifications
is a middle-man?

I don't think anything productive is likely to come out of this
conversation.  Let's just end this sub-thread.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256483

On Tue, 2015-10-27 at 15:00 +0900, Tejun Heo wrote:
> On Tue, Oct 27, 2015 at 06:56:42AM +0100, Mike Galbraith wrote:
> > > Well, if you think certain things are being missed, please speak up.
> > > Not in some media campaign way but with technical reasoning and
> > > justifications.
> > 
> > Inserting a middle-man is extremely unlikely to improve performance.
> 
> I'm not following you at all.  Technical reasoning and justifications
> is a middle-man?

No, user <-> systemd or whatever <-> kernel
             ^^^^^^^^^^^^^^^^^^^

> I don't think anything productive is likely to come out of this
> conversation.  Let's just end this sub-thread.

Agreed.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On Sun, Oct 25, 2015 at 11:18 AM, Tejun Heo <tj@kernel.org> wrote:
>
> We definitely need to weigh the inputs from heavy users but also need
> to discern the actual problems which need to be solved from the
> specific mechanisms chosen to solve them.  Let's please keep the
> discussions technical.  That's the best way to reach a viable
> long-term solution which can benefit a lot wider audience in the long
> term.  Even though that might not be the path of least immediate
> resistance, I believe that google will be an eventual beneficiary too.

So here's a somewhat odd request I got to hear very recently (at
LinuxCon EU in Ireland)..

A least some game engine writers apparently would like to be able to
set scheduling priorities for threads within a single process, because
they may want te game as a whole to have a certain priority, but then
some of the threads are critical for latency and may want certain
guaranteed resources (eg audio or actual gameplay) while others are
very much background things (garbage collection etc).

I suspect that's a very non-google use. We apparently don't really
support that kind of per-thread model right now at all.

Do they want cgroups? Maybe not. You can apparently do something like
this under Windows and OS X, but not under Linux (and I'm reporting
second-hand here, I don't know the exact details). I'm just bringing
it up as a somewhat unusual non-server thing that is certainly very
relevant despite being different.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255326

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sun, Oct 25, 2015 at 11:18 AM, Tejun Heo <tj@kernel.org> wrote:
> >
> > We definitely need to weigh the inputs from heavy users but also need to 
> > discern the actual problems which need to be solved from the specific 
> > mechanisms chosen to solve them.  Let's please keep the discussions technical.  
> > That's the best way to reach a viable long-term solution which can benefit a 
> > lot wider audience in the long term.  Even though that might not be the path 
> > of least immediate resistance, I believe that google will be an eventual 
> > beneficiary too.
> 
> So here's a somewhat odd request I got to hear very recently (at LinuxCon EU in 
> Ireland)..
> 
> A least some game engine writers apparently would like to be able to set 
> scheduling priorities for threads within a single process, because they may want 
> te game as a whole to have a certain priority, but then some of the threads are 
> critical for latency and may want certain guaranteed resources (eg audio or 
> actual gameplay) while others are very much background things (garbage 
> collection etc).
> 
> I suspect that's a very non-google use. We apparently don't really support that 
> kind of per-thread model right now at all.

Hm, that's weird - all our sched_*() system call APIs that set task scheduling 
priorities are fundamentally per thread, not per process. Same goes for the old 
sys_nice() interface. The scheduler has no real notion of 'process', and certainly 
not at the system call level.

This was always so and is expected to remain so in the future as well - and this 
is unrelated to cgroups.

> Do they want cgroups? Maybe not. You can apparently do something like this under 
> Windows and OS X, but not under Linux (and I'm reporting second-hand here, I 
> don't know the exact details). I'm just bringing it up as a somewhat unusual 
> non-server thing that is certainly very relevant despite being different.

So I'd realy like to hear about specifics, and they might be banging on open 
doors!

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255346

On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote:
> 
> Hm, that's weird - all our sched_*() system call APIs that set task scheduling 
> priorities are fundamentally per thread, not per process. Same goes for the old 
> sys_nice() interface. The scheduler has no real notion of 'process', and certainly 
> not at the system call level.
>

I suspect the main issue is that the games programmers were trying to
access it via libc / pthreads, which hides a lot of the power
available at the raw syscall level.  This is probably more of a
"tutorial needed for userspace programmers" issue, at a guess.

	  	     	       		    	   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255351

On 10/25/2015 11:41 AM, Theodore Ts'o wrote:
> On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote:
>>
>> Hm, that's weird - all our sched_*() system call APIs that set task scheduling 
>> priorities are fundamentally per thread, not per process. Same goes for the old 
>> sys_nice() interface. The scheduler has no real notion of 'process', and certainly 
>> not at the system call level.
>>
> 
> I suspect the main issue is that the games programmers were trying to
> access it via libc / pthreads, which hides a lot of the power
> available at the raw syscall level.  This is probably more of a
> "tutorial needed for userspace programmers" issue, at a guess.

If this refers to the lack of exposure of thread IDs in glibc, we are
willing to change that on glibc side.  The discussion has progressed to
the point where it is now about the question whether it should be part
of the GNU API (like sched_setaffinity), or live in glibc as a
Linux-specific extension (like sched_getcpu).  More input is certainly
welcome.

Old concerns about support for n:m threading implementations in glibc
are no longer relevant because too much code using well-documented
interfaces would break.

Florian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255370

On Sun, Oct 25, 2015 at 11:47:04AM +0100, Florian Weimer wrote:
> On 10/25/2015 11:41 AM, Theodore Ts'o wrote:
> > On Sun, Oct 25, 2015 at 10:33:32AM +0100, Ingo Molnar wrote:
> >>
> >> Hm, that's weird - all our sched_*() system call APIs that set task scheduling 
> >> priorities are fundamentally per thread, not per process. Same goes for the old 
> >> sys_nice() interface. The scheduler has no real notion of 'process', and certainly 
> >> not at the system call level.
> >>
> > 
> > I suspect the main issue is that the games programmers were trying to
> > access it via libc / pthreads, which hides a lot of the power
> > available at the raw syscall level.  This is probably more of a
> > "tutorial needed for userspace programmers" issue, at a guess.
> 
> If this refers to the lack of exposure of thread IDs in glibc, we are
> willing to change that on glibc side.  The discussion has progressed to
> the point where it is now about the question whether it should be part
> of the GNU API (like sched_setaffinity), or live in glibc as a
> Linux-specific extension (like sched_getcpu).  More input is certainly
> welcome.

Well, I was thinking we could just teach them to use
"syscall(SYS_gettid)".

On a different subject, I'm going to start telling people to use
"syscall(SYS_getrandom)", since I think that's going to be easier than
having asking people to change their Makefiles to link against some
Linux-specific library, but that's a different debate, and I recognize
the glibc folks aren't willing to bend on that one.

Cheers,

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255388

On 10/25/2015 12:58 PM, Theodore Ts'o wrote:

> Well, I was thinking we could just teach them to use
> "syscall(SYS_gettid)".

Right, and that's easier if TIDs are officially part of the GNU API.

I think the worry is that some future system might have TIDs which do
not share the PID space, or are real descriptors (that they need
explicit open and close operations).

> On a different subject, I'm going to start telling people to use
> "syscall(SYS_getrandom)", since I think that's going to be easier than
> having asking people to change their Makefiles to link against some
> Linux-specific library, but that's a different debate, and I recognize
> the glibc folks aren't willing to bend on that one.

I think we can reach consensus for an implementation which makes this code

  unsigned char session_key[32];
  getrandom (session_key, sizeof (session_key), 0);
  install_session_key (session_key);

correct.  That is, no error handling code for ENOMEM, ENOSYS, EINTR,
ENOMEM or short reads is necessary.  It seems that several getrandom
wrappers currently built into applications do not get this completely right.

Florian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255397 — Getrandom wrapper

On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote:
> 
> I think we can reach consensus for an implementation which makes this code
> 
>   unsigned char session_key[32];
>   getrandom (session_key, sizeof (session_key), 0);
>   install_session_key (session_key);
> 
> correct.  That is, no error handling code for ENOMEM, ENOSYS, EINTR,
> ENOMEM or short reads is necessary.  It seems that several getrandom
> wrappers currently built into applications do not get this completely right.

The only error handling code that is necessary is a fallback for
ENOSYS.  getrandom(2) won't return ENOMEM, and if the number of bytes
requested is less than or equal to 256 bytes, it won't return EINTR
either.  If the user requests more than 256 bytes, they're doing
something insane and almost certainly not cryptographic, and so
letting it be interruptible should be fine.  (OpenBSD will outright
*fail* a request greater than 256 bytes with an EIO error in their
getentropy(2) system call.  But that means the insane application
won't get any randomness at all in their overly large, insane request,
and if they're that insane, they're probably not checking error
conditions either.)

As far as ENOSYS is concerned, a fallback gets tricky; you could try
to open /dev/urandom, and read from it, but that can fail due to
EMFILE, ENFILE, ENOENT (if they are chrooted and /dev wasn't properly
populated).  So attempting a fallback for ENOSYS can actually expand
the number of potential error conditions for the userspace application
to (fail to) handle.  I suppose you could attempt the fallback and
call abort(2) if the fallback fails, which is probably the safe and
secure thing to do, but applications might not appreciate getting
terminated without getting a chance to do something (but if the
something is just calling random(3), maybe not giving them a chance to
do something insane is the appropriate thing to do....)

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1255910 — Re: Getrandom wrapper

On 10/25/2015 02:40 PM, Theodore Ts'o wrote:
> On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote:
>>
>> I think we can reach consensus for an implementation which makes this code
>>
>>   unsigned char session_key[32];
>>   getrandom (session_key, sizeof (session_key), 0);
>>   install_session_key (session_key);
>>
>> correct.  That is, no error handling code for ENOMEM, ENOSYS, EINTR,
>> ENOMEM or short reads is necessary.  It seems that several getrandom
>> wrappers currently built into applications do not get this completely right.
> 
> The only error handling code that is necessary is a fallback for
> ENOSYS.  getrandom(2) won't return ENOMEM, and if the number of bytes
> requested is less than or equal to 256 bytes, it won't return EINTR
> either.

Not even during early boot?  The code suggests that you can get EINTR if
the non-blocking pool isn't initialized yet.  With VMs, that
initialization can happen quite some time after boot, when the userland
is well under way.

> As far as ENOSYS is concerned, a fallback gets tricky; you could try
> to open /dev/urandom, and read from it, but that can fail due to
> EMFILE, ENFILE, ENOENT (if they are chrooted and /dev wasn't properly
> populated).  So attempting a fallback for ENOSYS can actually expand
> the number of potential error conditions for the userspace application
> to (fail to) handle.  I suppose you could attempt the fallback and
> call abort(2) if the fallback fails, which is probably the safe and
> secure thing to do, but applications might not appreciate getting
> terminated without getting a chance to do something (but if the
> something is just calling random(3), maybe not giving them a chance to
> do something insane is the appropriate thing to do....)

I'm more worried that the fallback code could be triggered
unexpectedly on some obscure code path that is not tested regularly, and
runs into a failure.  I suspect a high-quality implementation of
getrandom would have to open /dev/random and /devurandom when the
getrandom symbol is resolved, and report failure at that point, to avoid
late surprises.

Florian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1256046

On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote:
> On 10/25/2015 12:58 PM, Theodore Ts'o wrote:
> 
> > Well, I was thinking we could just teach them to use
> > "syscall(SYS_gettid)".
> 
> Right, and that's easier if TIDs are officially part of the GNU API.
> 
> I think the worry is that some future system might have TIDs which do
> not share the PID space, or are real descriptors (that they need
> explicit open and close operations).

For the scheduler the sharing of pid/tid space is not an issue.

Semantically all [1] scheduler syscalls take a tid. There isn't a single
syscall that iterates the thread group.

Even sys_setpriority() interprets its @who argument as a tid when
@which == PRIO_PROCESS (PRIO_PGRP looks to be the actual process).

[1] as seen from: git grep SYSCALL kernel/sched/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web