Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1200057 > unrolled thread
| Started by | Tejun Heo <tj@kernel.org> |
|---|---|
| First post | 2015-08-04 17:20 +0200 |
| Last post | 2015-09-02 19:10 +0200 |
| Articles | 20 on this page of 44 — 7 participants |
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.
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-04 17:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Peter Zijlstra <peterz@infradead.org> - 2015-08-05 11:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-05 16:40 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-17 22:40 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-18 06:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-18 22:40 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-08-19 01:50 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-19 18:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-08-19 05:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-19 18:50 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-08-20 06:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-20 10:00 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-08-20 10:50 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-21 21:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-22 20:40 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-08-24 17:50 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 19:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-08-24 21:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-08-24 22:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 22:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-24 23:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 23:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-24 23:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-24 23:00 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 23:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 23:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-24 23:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 23:50 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-25 00:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-25 01:00 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-25 01:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-08-25 04:40 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-25 23:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Ingo Molnar <mingo@kernel.org> - 2015-08-25 11:30 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Peter Zijlstra <peterz@infradead.org> - 2015-08-25 12:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-25 21:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-24 23:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-24 23:00 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-24 23:40 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-25 00:00 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-25 00:20 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Paul Turner <pjt@google.com> - 2015-08-25 01:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-08-25 23:10 +0200
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo <tj@kernel.org> - 2015-09-02 19:10 +0200
Page 1 of 3 [1] 2 3 Next page →
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-04 17:20 +0200 |
| Subject | Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy |
| Message-ID | <pTMaw-5Ud-75@gated-at.bofh.it> |
Hello, Peter. On Tue, Aug 04, 2015 at 11:07:11AM +0200, Peter Zijlstra wrote: > What about the unified hierarchy stuff cannot deal with per-task > controllers? > > _That_ was the biggest problem from what I can remember, and I see no > proposed resolution for that here. I've been thinking about it and I'm now convinced that cgroups just is the wrong interface to require each application to be programming against. I wrote this in the CAT thread too but cgroups may be an okay management / administration interface but is a horrible programming interface to be used by individual applications. For things which don't require hierarchy, the obvious thing to do is implementing a usual syscall-like interface be it a separate syscall, an prctl command, an ioctl or whatever. For things which require building a hierarchy of member threads, the right thing to do is making it a part of the usual process hierarchy - this is *the* hierarchy that applications are familiar with and have the facilities to deal with, so we can, for example, add a clone or unshare flag which puts the calling threads in a new child group and then let that use the fore-mentioned syscall-like interface to configure whatever it wants to configure. In the long term, this is *way* better than letting individual applications fumble with cgroup hierarchy delegation and pseudo filesystem access. If hierarchical weight and/or bandwidth limiting for thread hierarchy is absolutely necessary, doing this shouldn't be too difficult and I suspect it wouldn't be all that different from autogroup. > > * cpuacct is implictly enabled and disabled by cpu and its information > > is reported through "cpu.stat" which now uses microseconds for all > > time durations. All time duration fields now have "_usec" appended > > to them for clarity. While this doesn't solve the double accounting > > immediately, once majority of users switch to v2, cpu can directly > > account and report the relevant stats and cpuacct can be disabled on > > the unified hierarchy. > > > > Note that cpuacct.usage_percpu is currently not included in > > "cpu.stat". If this information is actually called for, it can be > > added later. > > Since you're rev'ing the interface, can't we simply kill the old cpuacct > and implement the missing pieces in cpu directly ? Yeah, that's the plan. For the transitional period however, we'd have a lot more usages where cpuacct is mounted in a legacy hierarchy so I didn't want to incur the overhead of duplicate accounting for those cases and the dependency mechanism is already there making it trivial. > > * "cpu.cfs_quota_us" and "cpu.cfs_period_us" are replaced by "cpu.max" > > which contains both quota and period. > > This is indeed a maximum limit, however > > > * "cpu.rt_runtime_us" and "cpu.rt_period_us" are replaced by > > "cpu.rt.max" which contains both runtime and period. > > the RT thing is conceptually more of a minimum guarantee, than a > maximum, even though the current implementation is both, there are plans > to allow (controlled) relaxation of the maximum part. Ah, I see. Yeah, then it should be cpu.rt.min. I'll just remove the file until the relaxation part is determined. > Also, if you're going to rev the interface, there's more changes we > should make. I'll have to go dig them out. Great, please let me know what you have on mind. 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]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-08-05 11:20 +0200 |
| Message-ID | <pU31E-5mp-7@gated-at.bofh.it> |
| In reply to | #1200057 |
On Tue, Aug 04, 2015 at 11:10:17AM -0400, Tejun Heo wrote: > Hello, Peter. > > On Tue, Aug 04, 2015 at 11:07:11AM +0200, Peter Zijlstra wrote: > > What about the unified hierarchy stuff cannot deal with per-task > > controllers? > > > > _That_ was the biggest problem from what I can remember, and I see no > > proposed resolution for that here. > > I've been thinking about it and I'm now convinced that cgroups just is > the wrong interface to require each application to be programming > against. But people are doing it. So you must give them something. You cannot just tell them to go away. So where are the people doing this in this discussion? Or are you one-sidedly forcing things? IIRC Google was doing this. The whole libvirt trainwreck also does this (the programming against cgroups, not the per task thing afaik). You also cannot mandate system-disease, not everybody will want to run that monster. From what I understood last time, Google has no interest what so ever of using it. > I wrote this in the CAT thread too but cgroups may be an > okay management / administration interface but is a horrible > programming interface to be used by individual applications. Yeah, I need to catch up on that CAT thread, but the reality is, people use it as a programming interface, whether you like it or not. > For things which don't require hierarchy, the obvious thing to do is > implementing a usual syscall-like interface be it a separate syscall, > an prctl command, an ioctl or whatever. And then you get /proc extensions to observe them, then people make those /proc extensions writable and before you know it you've got an equal or bigger mess back than you started out with :-( > For things which require > building a hierarchy of member threads, the right thing to do is > making it a part of the usual process hierarchy - this is *the* > hierarchy that applications are familiar with and have the facilities > to deal with, so we can, for example, add a clone or unshare flag > which puts the calling threads in a new child group and then let that > use the fore-mentioned syscall-like interface to configure whatever it > wants to configure. And then you get to add support to cgroups to migrate hierarchies, is that complexity you're waiting for? Not to mention that its an unwieldy interface because then you get spawn spawning threads etc.. Seeing how its impossible for the main thread to create N tasks in one subgroup and another M tasks in another subgroup. Instead they get to spawn a thread A, with which they then need to communicate to spawn a further N tasks, then spawn a thread B, and again communicate for another M tasks. That's a rather awkward change to how people usually spawn threads. Also, what to do when a thread changes profile? I can imagine a situation where a task accepts a connection and depending on the kind of request it gets, gets placed into a certain sub-group. But there's no migration facility, so you get to go hand the work around, which is expensive. If there would be a migration facility, you've just lost naming, so how are you going to denote the subgroups? > In the long term, this is *way* better than > letting individual applications fumble with cgroup hierarchy > delegation and pseudo filesystem access. You're worried about the intersection between what a task does and what the administrator does, and that's a valid worry. But I'm really not convinced this is going to make it better. We already have relative file ops (openat(), mkdirat(), unlinkat() etc..) can't we make sure they do the right thing in the face of a process (hierarchy) getting migrated by the administrator. That way, things at least _can_ work right, and I think being able to do the right thing trumps not being able to make a mess -- people are people, they'll always make a mess. > If hierarchical weight and/or bandwidth limiting for thread hierarchy > is absolutely necessary, doing this shouldn't be too difficult and I > suspect it wouldn't be all that different from autogroup. Autogroups are a bit icky and have the 'advantage' of not intersecting with regular cgroups (much). The above has intricate intersection with the cgroup stuff. As said, your migrate process becomes a move hierarchy. You further get more 'hidden' cgroups. /proc files that report what cgroup a task is in will report a cgroup that's not actually present in the filesystem (autogroups already does this, it confuses people). And as stated you take away a lot of things that are now possible. -- 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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-05 16:40 +0200 |
| Message-ID | <pU81k-483-27@gated-at.bofh.it> |
| In reply to | #1200568 |
Hello, On Wed, Aug 05, 2015 at 11:10:36AM +0200, Peter Zijlstra wrote: > > I've been thinking about it and I'm now convinced that cgroups just is > > the wrong interface to require each application to be programming > > against. > > But people are doing it. So you must give them something. You cannot > just tell them to go away. Sure, more on specifics later, but, first of all, the transition to v2 is a gradual process. The new and old hierarchies can co-exist, so nothing forces abrupt transitions. Also, we do want to start as restricted as possible and then widen it gradually as necessary. > So where are the people doing this in this discussion? Or are you > one-sidedly forcing things? IIRC Google was doing this. We've been having those discussions for years in person and on the cgroup mailing list. IIRC, the google case was for blkcg where they have an IO proxy process which wanna issue IOs as different cgroups depending on who's the original issuer. They created multiple threads, put them in different cgroups and bounce the IOs to the matching one; however, this is already pretty silly as they have to bounce IOs to different threads. What makes a lot more sense here is the ability to tag an IO as coming from a specific cgroup (or a process's cgroup) and there was discussion of using an extra field in aio request to indicate this, which is an a lot better solution for the problem, can also express different IO priority and pretty easy to implement. > The whole libvirt trainwreck also does this (the programming against > cgroups, not the per task thing afaik). AFAIK, libvirt is doing multiple backends anyway and as long as the delegation rules are clear, libvirt managing its own subhierarchy is not a problem. It's an administration software stack which requires fairly close integration with the userland part of operating system. > You also cannot mandate system-disease, not everybody will want to run > that monster. From what I understood last time, Google has no interest > what so ever of using it. But what would require tight coupling of individual applications and something like systemd is the kernel failing to set up a reasonable boundary between management and application interfaces. If the kernel provides a useable API for individual applications to use, they'll program against it and the management part can be whatever. If we fail to do that, individual applications will have to talk to external agent to coordinate access to management interface and that's what'll end up creating hard dependency on specific system agents from applications like apache or mysql or whatever. We really don't want that. The kernel *NEEDS* to clearly distinguish those two to prevent that from happening. > > I wrote this in the CAT thread too but cgroups may be an > > okay management / administration interface but is a horrible > > programming interface to be used by individual applications. > > Yeah, I need to catch up on that CAT thread, but the reality is, people > use it as a programming interface, whether you like it or not. And that's one of the major fuck ups on cgroup's part that must be rectified. Look at the interface being proposed there. It's exposing direct hardware details w/o much abstraction which is fine for a system management interface but at the same time it's intended to be exposed to individual applications. This lack of distinction makes people skip the attention that they should be paying when they're designing interface exposed to individual programs. Worse, this makes these things fly under the review scrutiny that public API accessible to applications usually receives. Yet, that's what these things end up to be. This just has to stop. cgroups can't continue to be this ghetto shortcut to implementing half-assed APIs. > > For things which don't require hierarchy, the obvious thing to do is > > implementing a usual syscall-like interface be it a separate syscall, > > an prctl command, an ioctl or whatever. > > And then you get /proc extensions to observe them, then people make > those /proc extensions writable and before you know it you've got an > equal or bigger mess back than you started out with :-( What we should be doing is pushing them into the same arena as any other publicly accessible API. I don't think there can be a shortcut to this. > > For things which require > > building a hierarchy of member threads, the right thing to do is > > making it a part of the usual process hierarchy - this is *the* > > hierarchy that applications are familiar with and have the facilities > > to deal with, so we can, for example, add a clone or unshare flag > > which puts the calling threads in a new child group and then let that > > use the fore-mentioned syscall-like interface to configure whatever it > > wants to configure. > > And then you get to add support to cgroups to migrate hierarchies, is > that complexity you're waiting for? Absolutely, if it comes to that, that's what we should do. The only other option is spilling and getting locked into half-baked interface to applications which not only harm userland but also kernel. > Not to mention that its an unwieldy interface because then you get spawn > spawning threads etc.. Seeing how its impossible for the main thread to > create N tasks in one subgroup and another M tasks in another subgroup. > > Instead they get to spawn a thread A, with which they then need to > communicate to spawn a further N tasks, then spawn a thread B, and again > communicate for another M tasks. > > That's a rather awkward change to how people usually spawn threads. It is within the usual purview of how userland deals with hierarchies of processes / threads and I don't think it's necessarily bad and more importantly I don't think the use case or the perceived awkwardness justifies introducing a wholely new mechanism. > Also, what to do when a thread changes profile? I can imagine a > situation where a task accepts a connection and depending on the kind of > request it gets, gets placed into a certain sub-group. Migration is a very expensive operation. The obvious thing to do for such cases is having pools of workers for different profiles. Also, as mentioned before, for more specific cases like IO, it makes a lot more sense to override things per operation rather than moving threads around. > But there's no migration facility, so you get to go hand the work > around, which is expensive. That's a lot cheaper than migrating. > If there would be a migration facility, you've just lost naming, so how > are you going to denote the subgroups? I don't think we want migration in sub-process hierarchy but in the off chance we do the naming can follow the same pid/program group/session id scheme, which, again, is a lot easier to deal with from applications. > > In the long term, this is *way* better than > > letting individual applications fumble with cgroup hierarchy > > delegation and pseudo filesystem access. > > You're worried about the intersection between what a task does and what > the administrator does, and that's a valid worry. But I'm really not > convinced this is going to make it better. > > We already have relative file ops (openat(), mkdirat(), unlinkat() > etc..) can't we make sure they do the right thing in the face of a > process (hierarchy) getting migrated by the administrator. But those are relative to the current directory per operation and there's no way to define a transaction across multiple file operations. There's no way to prevent a process from being migrated inbetween openat() and subsequent write(). > That way, things at least _can_ work right, and I think being able to do > the right thing trumps not being able to make a mess -- people are > people, they'll always make a mess. It can't, at least not in the usual manner that file system operations are defined. This is an interface which requires central coordination (even for delegation) and a horrible one to expose to individual applications. > > If hierarchical weight and/or bandwidth limiting for thread hierarchy > > is absolutely necessary, doing this shouldn't be too difficult and I > > suspect it wouldn't be all that different from autogroup. > > Autogroups are a bit icky and have the 'advantage' of not intersecting > with regular cgroups (much). The above has intricate intersection with > the cgroup stuff. > > As said, your migrate process becomes a move hierarchy. You further get > more 'hidden' cgroups. /proc files that report what cgroup a task is in > will report a cgroup that's not actually present in the filesystem > (autogroups already does this, it confuses people). And as stated you > take away a lot of things that are now possible. I don't think it's a lot that per-process is gonna take away. Per-thread use cases are pretty niche to begin with and most can and should be implemented better using a more fitting mechanism. As for having to deal with more complexity in cgroup core, that's fine. If it comes to that, we'll have to bite the bullet and do it. Sure, we want to be simpler but not at the cost of messing up userland API and please note that what we lost with cgroups is this tension. This tension between the difficulty and complexity of implementing something which can be used by applications and the necessity or desirability of the proposed use cases is crucial in steering kernel development and the APIs it exposes. Abusing cgroups like we've been doing bypasses that tension and we of course end up locked into an extremely crappy interfaces and mechanisms which could never be justified in the first place. This is about time we stopped this disaster train. 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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-17 22:40 +0200 |
| Message-ID | <pYzmi-1k5-15@gated-at.bofh.it> |
| In reply to | #1200833 |
Hello, Peter. Do we have an agreement on the sched changes? Thanks a lot. -- 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]
| From | Paul Turner <pjt@google.com> |
|---|---|
| Date | 2015-08-18 06:10 +0200 |
| Subject | Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy |
| Message-ID | <pYGnL-3k7-3@gated-at.bofh.it> |
| In reply to | #1200833 |
Apologies for the repeat. Gmail ate its plain text setting for some reason. Shame bells. On Mon, Aug 17, 2015 at 9:02 PM, Paul Turner <pjt@google.com> wrote: > > > On Wed, Aug 5, 2015 at 7:31 AM, Tejun Heo <tj@kernel.org> wrote: >> >> Hello, >> >> On Wed, Aug 05, 2015 at 11:10:36AM +0200, Peter Zijlstra wrote: >> > > I've been thinking about it and I'm now convinced that cgroups just is >> > > the wrong interface to require each application to be programming >> > > against. >> > >> > But people are doing it. So you must give them something. You cannot >> > just tell them to go away. >> >> Sure, more on specifics later, but, first of all, the transition to v2 >> is a gradual process. The new and old hierarchies can co-exist, so >> nothing forces abrupt transitions. Also, we do want to start as >> restricted as possible and then widen it gradually as necessary. >> >> > So where are the people doing this in this discussion? Or are you >> > one-sidedly forcing things? IIRC Google was doing this. >> >> We've been having those discussions for years in person and on the >> cgroup mailing list. IIRC, the google case was for blkcg where they >> have an IO proxy process which wanna issue IOs as different cgroups >> depending on who's the original issuer. They created multiple >> threads, put them in different cgroups and bounce the IOs to the >> matching one; however, this is already pretty silly as they have to >> bounce IOs to different threads. What makes a lot more sense here is >> the ability to tag an IO as coming from a specific cgroup (or a >> process's cgroup) and there was discussion of using an extra field in >> aio request to indicate this, which is an a lot better solution for >> the problem, can also express different IO priority and pretty easy to >> implement. >> > > So we have two major types of use that are relevant to this interface: > > 1) Proxy agents. When a control systems want to perform work on behalf of a > container, they will sometimes move the acting thread into the relevant > control groups so that it can be accounted on that container's behalf. > [This is more relevant for non-persistent resources such as CPU time or I/O > priorities than charges that will outlive the work such as memory > allocations.] > > I agree (1) is at best a bit of a hack and can be worked around on the type > of time-frame these interfaces move at. > > 2) Control within an address-space. For subsystems with fungible resources, > e.g. CPU, it can be useful for an address space to partition its own > threads. Losing the capability to do this against the CPU controller would > be a large set-back for instance. Occasionally, it is useful to share these > groupings between address spaces when processes are cooperative, but this is > less of a requirement. > > This is important to us. > > >> > The whole libvirt trainwreck also does this (the programming against >> > cgroups, not the per task thing afaik). >> >> AFAIK, libvirt is doing multiple backends anyway and as long as the >> delegation rules are clear, libvirt managing its own subhierarchy is >> not a problem. It's an administration software stack which requires >> fairly close integration with the userland part of operating system. >> >> > You also cannot mandate system-disease, not everybody will want to run >> > that monster. From what I understood last time, Google has no interest >> > what so ever of using it. >> >> But what would require tight coupling of individual applications and >> something like systemd is the kernel failing to set up a reasonable >> boundary between management and application interfaces. If the kernel >> provides a useable API for individual applications to use, they'll >> program against it and the management part can be whatever. If we >> fail to do that, individual applications will have to talk to external >> agent to coordinate access to management interface > > > It's notable here that for a managed system, the agent coordinating access > *must* be external > >> >> and that's what'll >> end up creating hard dependency on specific system agents from >> applications like apache or mysql or whatever. We really don't want >> that. The kernel *NEEDS* to clearly distinguish those two to prevent >> that from happening. >> >> > > I wrote this in the CAT thread too but cgroups may be an >> > > okay management / administration interface but is a horrible >> > > programming interface to be used by individual applications. >> > >> > Yeah, I need to catch up on that CAT thread, but the reality is, people >> > use it as a programming interface, whether you like it or not. >> >> And that's one of the major fuck ups on cgroup's part that must be >> rectified. Look at the interface being proposed there. It's exposing >> direct hardware details w/o much abstraction which is fine for a >> system management interface but at the same time it's intended to be >> exposed to individual applications. > > > FWIW this is something we've had no significant problems managing with > separate mount mounts and file system protections. Yes, there are some > potential warts around atomicity; but we've not found them too onerous. > > What I don't quite follow here is the assumption that CAT should would be > necessarily exposed to individual applications? What's wrong with subsystems > that are primarily intended only for system management agents, we already > have several of these. > > >> >> This lack of distinction makes >> people skip the attention that they should be paying when they're >> designing interface exposed to individual programs. Worse, this makes >> these things fly under the review scrutiny that public API accessible >> to applications usually receives. Yet, that's what these things end >> up to be. This just has to stop. cgroups can't continue to be this >> ghetto shortcut to implementing half-assed APIs. > > > I certainly don't disagree on this point :). But as above, I don't quite > follow why an API being in cgroups must mean it's accessible to an > application controlled by that group. This has certainly not been a > requirement for our use. > >> >> >> > > For things which don't require hierarchy, the obvious thing to do is >> > > implementing a usual syscall-like interface be it a separate syscall, >> > > an prctl command, an ioctl or whatever. >> > >> > And then you get /proc extensions to observe them, then people make >> > those /proc extensions writable and before you know it you've got an >> > equal or bigger mess back than you started out with :-( >> >> What we should be doing is pushing them into the same arena as any >> other publicly accessible API. I don't think there can be a shortcut >> to this. >> > > Are you explicitly opposed to non-hierarchical partitions, however? Cpuset > is [typically] an example of this, where the interface wants to control > unified properties across a set of processes. Without necessarily being > usefully hierarchical. (This is just to understand your core position, I'm > not proposing cpuset should shape *anything*.) > >> >> > > For things which require >> > > building a hierarchy of member threads, the right thing to do is >> > > making it a part of the usual process hierarchy - this is *the* >> > > hierarchy that applications are familiar with and have the facilities >> > > to deal with, so we can, for example, add a clone or unshare flag >> > > which puts the calling threads in a new child group and then let that >> > > use the fore-mentioned syscall-like interface to configure whatever it >> > > wants to configure. >> > >> > And then you get to add support to cgroups to migrate hierarchies, is >> > that complexity you're waiting for? >> >> Absolutely, if it comes to that, that's what we should do. The only >> other option is spilling and getting locked into half-baked interface >> to applications which not only harm userland but also kernel. >> >> > Not to mention that its an unwieldy interface because then you get spawn >> > spawning threads etc.. Seeing how its impossible for the main thread to >> > create N tasks in one subgroup and another M tasks in another subgroup. >> > >> > Instead they get to spawn a thread A, with which they then need to >> > communicate to spawn a further N tasks, then spawn a thread B, and again >> > communicate for another M tasks. >> > >> > That's a rather awkward change to how people usually spawn threads. >> >> It is within the usual purview of how userland deals with hierarchies >> of processes / threads and I don't think it's necessarily bad and more >> importantly I don't think the use case or the perceived awkwardness >> justifies introducing a wholely new mechanism. >> >> > Also, what to do when a thread changes profile? I can imagine a >> > situation where a task accepts a connection and depending on the kind of >> > request it gets, gets placed into a certain sub-group. >> >> Migration is a very expensive operation. The obvious thing to do for >> such cases is having pools of workers for different profiles. Also, >> as mentioned before, for more specific cases like IO, it makes a lot >> more sense to override things per operation rather than moving threads >> around. >> >> > But there's no migration facility, so you get to go hand the work >> > around, which is expensive. >> >> That's a lot cheaper than migrating. >> >> > If there would be a migration facility, you've just lost naming, so how >> > are you going to denote the subgroups? >> >> I don't think we want migration in sub-process hierarchy but in the >> off chance we do the naming can follow the same pid/program >> group/session id scheme, which, again, is a lot easier to deal with >> from applications. > > > I don't have many objections with hand-off versus migration above, however, > I think that this is a big drawback. Threads are expensive to create and > are often cached rather than released. While migration may be expensive, > creating a more thread is more so. The important to reconfigure a thread's > personality at run-time is important. > >> >> > > In the long term, this is *way* better than >> > > letting individual applications fumble with cgroup hierarchy >> > > delegation and pseudo filesystem access. >> > >> > You're worried about the intersection between what a task does and what >> > the administrator does, and that's a valid worry. But I'm really not >> > convinced this is going to make it better. >> > >> > We already have relative file ops (openat(), mkdirat(), unlinkat() >> > etc..) can't we make sure they do the right thing in the face of a >> > process (hierarchy) getting migrated by the administrator. >> >> But those are relative to the current directory per operation and >> there's no way to define a transaction across multiple file >> operations. There's no way to prevent a process from being migrated >> inbetween openat() and subsequent write(). > > > A forwarding /proc/thread_self/cgroup accessor, or similar, would be another > way to address some of these issues. > >> >> >> > That way, things at least _can_ work right, and I think being able to do >> > the right thing trumps not being able to make a mess -- people are >> > people, they'll always make a mess. >> >> It can't, at least not in the usual manner that file system operations >> are defined. This is an interface which requires central coordination >> (even for delegation) and a horrible one to expose to individual >> applications. >> >> > > If hierarchical weight and/or bandwidth limiting for thread hierarchy >> > > is absolutely necessary, doing this shouldn't be too difficult and I >> > > suspect it wouldn't be all that different from autogroup. >> > >> > Autogroups are a bit icky and have the 'advantage' of not intersecting >> > with regular cgroups (much). The above has intricate intersection with >> > the cgroup stuff. >> > >> > As said, your migrate process becomes a move hierarchy. You further get >> > more 'hidden' cgroups. /proc files that report what cgroup a task is in >> > will report a cgroup that's not actually present in the filesystem >> > (autogroups already does this, it confuses people). And as stated you >> > take away a lot of things that are now possible. >> >> I don't think it's a lot that per-process is gonna take away. >> Per-thread use cases are pretty niche to begin with and most can and >> should be implemented better using a more fitting mechanism. As for >> having to deal with more complexity in cgroup core, that's fine. If >> it comes to that, we'll have to bite the bullet and do it. Sure, we >> want to be simpler but not at the cost of messing up userland API and >> please note that what we lost with cgroups is this tension. > > > I don't quite agree here. Losing per-thread control within the cpu > controller is likely going to mean that much of it ends up being > reimplemented as some duplicate-in-appearance interface that gets us back to > where we are today. I recognize that these controllers (cpu, cpuacct) are > square pegs in that per-process makes sense for most other sub-systems; but > unfortunately, their needs and use-cases are real / dependent on their > present form. > >> >> This tension between the difficulty and complexity of implementing >> something which can be used by applications and the necessity or >> desirability of the proposed use cases is crucial in steering kernel >> development and the APIs it exposes. Abusing cgroups like we've been >> doing bypasses that tension and we of course end up locked into an >> extremely crappy interfaces and mechanisms which could never be >> justified in the first place. This is about time we stopped this >> disaster train. >> >> 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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-18 22:40 +0200 |
| Message-ID | <pYVPQ-im-11@gated-at.bofh.it> |
| In reply to | #1209027 |
Hello, Paul. On Mon, Aug 17, 2015 at 09:03:30PM -0700, Paul Turner wrote: > > 2) Control within an address-space. For subsystems with fungible resources, > > e.g. CPU, it can be useful for an address space to partition its own > > threads. Losing the capability to do this against the CPU controller would > > be a large set-back for instance. Occasionally, it is useful to share these > > groupings between address spaces when processes are cooperative, but this is > > less of a requirement. > > > > This is important to us. Sure, let's build a proper interface for that. Do you actually need sub-hierarchy inside a process? Can you describe your use case in detail and why having hierarchical CPU cycle distribution is essential for your use case? > >> And that's one of the major fuck ups on cgroup's part that must be > >> rectified. Look at the interface being proposed there. It's exposing > >> direct hardware details w/o much abstraction which is fine for a > >> system management interface but at the same time it's intended to be > >> exposed to individual applications. > > > > FWIW this is something we've had no significant problems managing with > > separate mount mounts and file system protections. Yes, there are some > > potential warts around atomicity; but we've not found them too onerous. You guys control the whole stack. Of course, you can get away with an interface which are pretty messed up in terms of layering and isolation; however, generic kernel interface cannot be designed according to that standard. > > What I don't quite follow here is the assumption that CAT should would be > > necessarily exposed to individual applications? What's wrong with subsystems > > that are primarily intended only for system management agents, we already > > have several of these. Why would you assume that threads of a process wouldn't want to configure it ever? How is this different from CPU affinity? > >> This lack of distinction makes > >> people skip the attention that they should be paying when they're > >> designing interface exposed to individual programs. Worse, this makes > >> these things fly under the review scrutiny that public API accessible > >> to applications usually receives. Yet, that's what these things end > >> up to be. This just has to stop. cgroups can't continue to be this > >> ghetto shortcut to implementing half-assed APIs. > > > > I certainly don't disagree on this point :). But as above, I don't quite > > follow why an API being in cgroups must mean it's accessible to an > > application controlled by that group. This has certainly not been a > > requirement for our use. I don't follow what you're trying to way with the above paragraph. Are you still talking about CAT? If so, that use case isn't the only one. I'm pretty sure there are people who would want to configure cache allocation at thread level. > >> What we should be doing is pushing them into the same arena as any > >> other publicly accessible API. I don't think there can be a shortcut > >> to this. > > > > Are you explicitly opposed to non-hierarchical partitions, however? Cpuset > > is [typically] an example of this, where the interface wants to control > > unified properties across a set of processes. Without necessarily being > > usefully hierarchical. (This is just to understand your core position, I'm > > not proposing cpuset should shape *anything*.) I'm having trouble following what you're trying to say. FWIW, cpuset is fully hierarchical. > >> I don't think we want migration in sub-process hierarchy but in the > >> off chance we do the naming can follow the same pid/program > >> group/session id scheme, which, again, is a lot easier to deal with > >> from applications. > > > > I don't have many objections with hand-off versus migration above, however, > > I think that this is a big drawback. Threads are expensive to create and > > are often cached rather than released. While migration may be expensive, > > creating a more thread is more so. The important to reconfigure a thread's > > personality at run-time is important. The core problem here is picking the hot path. If cgroups as a whole doesn't pick a position here, controllers have to assume that migration might not be a very cold path which naturally leads to overall designs and synchronization schemes which concede hot path performance to accomodate migration. We simply can't afford to do that - we end up losing way more in way hotter paths for something which may be marginally useful in some corner cases. So, this is a trade-off we're consciously making. If there are common-enough use cases which require jumping across different cgroup domains, we'll try to figure out a way to accomodate those but by default migration is a very cold and expensive path. > >> But those are relative to the current directory per operation and > >> there's no way to define a transaction across multiple file > >> operations. There's no way to prevent a process from being migrated > >> inbetween openat() and subsequent write(). > > > > A forwarding /proc/thread_self/cgroup accessor, or similar, would be another > > way to address some of these issues. That sounds horrible to me. What if the process wants to do RMW a config? What if the permissions are different after an intervening migration? What if the sub-hierarchy no longer exists or has been replaced by a hierarchy with the same topology but actualy is a different one? > > I don't quite agree here. Losing per-thread control within the cpu > > controller is likely going to mean that much of it ends up being > > reimplemented as some duplicate-in-appearance interface that gets us back to > > where we are today. I recognize that these controllers (cpu, cpuacct) are > > square pegs in that per-process makes sense for most other sub-systems; but > > unfortunately, their needs and use-cases are real / dependent on their > > present form. Let's build an API which actually looks and behaves like an API which is properly isolated from what external agents may do to the process. I can't see how that would be "back to where we are today". All of those are pretty critical attributes for a public kernel API and utterly broken right 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]
| From | Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> |
|---|---|
| Date | 2015-08-19 01:50 +0200 |
| Message-ID | <pYYNI-5lR-9@gated-at.bofh.it> |
| In reply to | #1209470 |
On 2015/08/19 5:31, Tejun Heo wrote: > Hello, Paul. > > On Mon, Aug 17, 2015 at 09:03:30PM -0700, Paul Turner wrote: >>> 2) Control within an address-space. For subsystems with fungible resources, >>> e.g. CPU, it can be useful for an address space to partition its own >>> threads. Losing the capability to do this against the CPU controller would >>> be a large set-back for instance. Occasionally, it is useful to share these >>> groupings between address spaces when processes are cooperative, but this is >>> less of a requirement. >>> >>> This is important to us. > > Sure, let's build a proper interface for that. Do you actually need > sub-hierarchy inside a process? Can you describe your use case in > detail and why having hierarchical CPU cycle distribution is essential > for your use case? An actual per-thread use case in our customers is qemu-kvm + cpuset. customers pin each vcpus and qemu-kvm's worker threads to cpus. For example, pinning 4 vcpus to cpu 2-6 and pinning qemu main thread and others(vhost) to cpu 0-1. This is an actual kvm tuning on our customers for performance guarantee. In another case, cpu cgroup's throttling feature is used per vcpu for vm cpu sizing. Thanks, -Kame -- 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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-19 18:30 +0200 |
| Message-ID | <pZeps-2N8-5@gated-at.bofh.it> |
| In reply to | #1209544 |
Hello, Kame. On Wed, Aug 19, 2015 at 08:39:43AM +0900, Kamezawa Hiroyuki wrote: > An actual per-thread use case in our customers is qemu-kvm + cpuset. > customers pin each vcpus and qemu-kvm's worker threads to cpus. > For example, pinning 4 vcpus to cpu 2-6 and pinning qemu main thread and > others(vhost) to cpu 0-1. taskset and/or teach qemu how to confiure its worker threads? > This is an actual kvm tuning on our customers for performance guarantee. > > In another case, cpu cgroup's throttling feature is used per vcpu for vm cpu sizing. Yeap, this is something we likely want to implement in an accessible way. For kvm, per-thread throttling configuration is enough, right? 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]
| From | Mike Galbraith <umgwanakikbuti@gmail.com> |
|---|---|
| Date | 2015-08-19 05:30 +0200 |
| Message-ID | <pZ2eC-1XG-3@gated-at.bofh.it> |
| In reply to | #1209470 |
On Tue, 2015-08-18 at 13:31 -0700, Tejun Heo wrote: > So, this is a trade-off we're consciously making. If there are > common-enough use cases which require jumping across different cgroup > domains, we'll try to figure out a way to accomodate those but by > default migration is a very cold and expensive path. 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. -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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-19 18:50 +0200 |
| Message-ID | <pZeIO-39Y-19@gated-at.bofh.it> |
| In reply to | #1209593 |
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@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]
| From | Mike Galbraith <umgwanakikbuti@gmail.com> |
|---|---|
| Date | 2015-08-20 06:10 +0200 |
| Message-ID | <pZpkS-1Os-3@gated-at.bofh.it> |
| In reply to | #1209952 |
On Wed, 2015-08-19 at 09:41 -0700, Tejun Heo wrote: > 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. 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 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. 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. 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. -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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-20 10:00 +0200 |
| Message-ID | <pZsVs-70t-29@gated-at.bofh.it> |
| In reply to | #1210134 |
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@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]
| From | Mike Galbraith <umgwanakikbuti@gmail.com> |
|---|---|
| Date | 2015-08-20 10:50 +0200 |
| Message-ID | <pZtHQ-8aH-19@gated-at.bofh.it> |
| In reply to | #1210254 |
On Thu, 2015-08-20 at 00:52 -0700, Tejun Heo wrote: > 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. Yes, ms latencies ever coming back is the concern, whether that be due to something akin to the old synchronize_rcu() horror.. or some handoff of whatever to whomever. -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]
| From | Paul Turner <pjt@google.com> |
|---|---|
| Date | 2015-08-21 21:30 +0200 |
| Subject | Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy |
| Message-ID | <q00aK-4yo-29@gated-at.bofh.it> |
| In reply to | #1209470 |
On Tue, Aug 18, 2015 at 1:31 PM, Tejun Heo <tj@kernel.org> wrote: > Hello, Paul. > > On Mon, Aug 17, 2015 at 09:03:30PM -0700, Paul Turner wrote: >> > 2) Control within an address-space. For subsystems with fungible resources, >> > e.g. CPU, it can be useful for an address space to partition its own >> > threads. Losing the capability to do this against the CPU controller would >> > be a large set-back for instance. Occasionally, it is useful to share these >> > groupings between address spaces when processes are cooperative, but this is >> > less of a requirement. >> > >> > This is important to us. > > Sure, let's build a proper interface for that. Do you actually need > sub-hierarchy inside a process? Can you describe your use case in > detail and why having hierarchical CPU cycle distribution is essential > for your use case? > One common example here is a thread-pool. Having a hierarchical constraint allows users to specify what proportion of time it should receive, independent of how many threads are placed in the pool. A very concrete example of the above is a virtual machine in which you want to guarantee scheduling for the vCPU threads which must schedule beside many hypervisor support threads. A hierarchy is the only way to fix the ratio at which these compete. An example that's not the cpu controller is that we use cpusets to expose to applications their "shared" and "private" cores. (These sets are dynamic based on what is coscheduled on a given machine.) >> >> And that's one of the major fuck ups on cgroup's part that must be >> >> rectified. Look at the interface being proposed there. It's exposing >> >> direct hardware details w/o much abstraction which is fine for a >> >> system management interface but at the same time it's intended to be >> >> exposed to individual applications. >> > >> > FWIW this is something we've had no significant problems managing with >> > separate mount mounts and file system protections. Yes, there are some >> > potential warts around atomicity; but we've not found them too onerous. > > You guys control the whole stack. Of course, you can get away with an > interface which are pretty messed up in terms of layering and > isolation; however, generic kernel interface cannot be designed > according to that standard. I feel like two points are being conflated here: Yes, it is sufficiently generic that it's possible to configure nonsensical things. But, it is also possible to lock things down presently. This is, for better or worse, the direction that general user-space has also taken with centralized management daemons such as systemd. Setting design aside for a moment -- which I fully agree with you that there is room for large improvement in. The largest idiosyncrasy today is that the configuration above does depend on having a stable mount point for applications to manage their sub-hierarchies. Migrations would improve this greatly, but this is a bit of a detour because you're looking to fix the fundamental design rather than improve the state of the world and that's probably a good thing :) > >> > What I don't quite follow here is the assumption that CAT should would be >> > necessarily exposed to individual applications? What's wrong with subsystems >> > that are primarily intended only for system management agents, we already >> > have several of these. > > Why would you assume that threads of a process wouldn't want to > configure it ever? How is this different from CPU affinity? In general cache and CPU behave differently. Generally for it to make sense between threads in a process they would have to have wholly disjoint memory, at which point the only sane long-term implementation is separate processes and the management moves up a level anyway. That said, there are surely cases in which it might be convenient to use at a per-thread level to correct a specific performance anomaly. But at that point, you have certainly reached the level of hammer that you can coordinate with an external daemon if necessary. > >> >> This lack of distinction makes >> >> people skip the attention that they should be paying when they're >> >> designing interface exposed to individual programs. Worse, this makes >> >> these things fly under the review scrutiny that public API accessible >> >> to applications usually receives. Yet, that's what these things end >> >> up to be. This just has to stop. cgroups can't continue to be this >> >> ghetto shortcut to implementing half-assed APIs. >> > >> > I certainly don't disagree on this point :). But as above, I don't quite >> > follow why an API being in cgroups must mean it's accessible to an >> > application controlled by that group. This has certainly not been a >> > requirement for our use. > > I don't follow what you're trying to way with the above paragraph. > Are you still talking about CAT? If so, that use case isn't the only > one. I'm pretty sure there are people who would want to configure > cache allocation at thread level. I'm not agreeing with you that "in cgroups" means "must be usable by applications within that hierarchy". A cgroup subsystem used as a partitioning API only by system management daemons is entirely reasonable. CAT is a reasonable example of this. > >> >> What we should be doing is pushing them into the same arena as any >> >> other publicly accessible API. I don't think there can be a shortcut >> >> to this. >> > >> > Are you explicitly opposed to non-hierarchical partitions, however? Cpuset >> > is [typically] an example of this, where the interface wants to control >> > unified properties across a set of processes. Without necessarily being >> > usefully hierarchical. (This is just to understand your core position, I'm >> > not proposing cpuset should shape *anything*.) > > I'm having trouble following what you're trying to say. FWIW, cpuset > is fully hierarchical. I think where I was going with this is better addressed above. Here all I meant is that it's difficult to construct useful sub-hierarchies on the cpuset side, especially for memory. But this is a little x86-centric so let's drop it. > >> >> I don't think we want migration in sub-process hierarchy but in the >> >> off chance we do the naming can follow the same pid/program >> >> group/session id scheme, which, again, is a lot easier to deal with >> >> from applications. >> > >> > I don't have many objections with hand-off versus migration above, however, >> > I think that this is a big drawback. Threads are expensive to create and >> > are often cached rather than released. While migration may be expensive, >> > creating a more thread is more so. The important to reconfigure a thread's >> > personality at run-time is important. > > The core problem here is picking the hot path. If cgroups as a whole > doesn't pick a position here, controllers have to assume that > migration might not be a very cold path which naturally leads to > overall designs and synchronization schemes which concede hot path > performance to accomodate migration. We simply can't afford to do > that - we end up losing way more in way hotter paths for something > which may be marginally useful in some corner cases. > > So, this is a trade-off we're consciously making. If there are > common-enough use cases which require jumping across different cgroup > domains, we'll try to figure out a way to accomodate those but by > default migration is a very cold and expensive path. > The core here was the need for allowing sub-process migration. I'm not sure I follow the performance trade-off argument; haven't we historically seen the opposite? That migration has been a slow-path without optimizations and people pushing to make it faster? This seems a hard generalization to make for something that's inherently tied to a particular controller. I don't care if we try turning that dial back to assume it's a cold path once more, only that it's supported. >> >> But those are relative to the current directory per operation and >> >> there's no way to define a transaction across multiple file >> >> operations. There's no way to prevent a process from being migrated >> >> inbetween openat() and subsequent write(). >> > >> > A forwarding /proc/thread_self/cgroup accessor, or similar, would be another >> > way to address some of these issues. > > That sounds horrible to me. What if the process wants to do RMW a > config? Locking within a process is easy. > What if the permissions are different after an intervening > migration? This is a side-effect of migration not being properly supported. > What if the sub-hierarchy no longer exists or has been > replaced by a hierarchy with the same topology but actualy is a > different one? The easy answer is that: Only a process should be managing its sub-hierarchy. That's the nice thing about hierarchies. The harder answer is: How do we handle non-fungible resources such as CPU assignments within a hierarchy? This is a big part of why I make arguments for certain partitions being management-software only above. This is imperfect, but better then where we stand today. > >> > I don't quite agree here. Losing per-thread control within the cpu >> > controller is likely going to mean that much of it ends up being >> > reimplemented as some duplicate-in-appearance interface that gets us back to >> > where we are today. I recognize that these controllers (cpu, cpuacct) are >> > square pegs in that per-process makes sense for most other sub-systems; but >> > unfortunately, their needs and use-cases are real / dependent on their >> > present form. > > Let's build an API which actually looks and behaves like an API which > is properly isolated from what external agents may do to the process. > I can't see how that would be "back to where we are today". All of > those are pretty critical attributes for a public kernel API and > utterly broken right now. > Sure, but I don't think you can throw out per-thread control for all controllers to enable this. Which makes everything else harder. A intermediary step in unification might be that we move from N mounts to 2. Those that can be managed at the process level, and those that can't. It's a compromise, but may allow cleaner abstractions for the former case. -- 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]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-22 20:40 +0200 |
| Message-ID | <q0lRT-1MU-1@gated-at.bofh.it> |
| In reply to | #1211303 |
Hello, Paul. On Fri, Aug 21, 2015 at 12:26:30PM -0700, Paul Turner wrote: ... > A very concrete example of the above is a virtual machine in which you > want to guarantee scheduling for the vCPU threads which must schedule > beside many hypervisor support threads. A hierarchy is the only way > to fix the ratio at which these compete. Just to learn more, what sort of hypervisor support threads are we talking about? They would have to consume considerable amount of cpu cycles for problems like this to be relevant and be dynamic in numbers in a way which letting them competing against vcpus makes sense. Do IO helpers meet these criteria? > An example that's not the cpu controller is that we use cpusets to > expose to applications their "shared" and "private" cores. (These > sets are dynamic based on what is coscheduled on a given machine.) Can you please go into more details with these? > > Why would you assume that threads of a process wouldn't want to > > configure it ever? How is this different from CPU affinity? > > In general cache and CPU behave differently. Generally for it to make > sense between threads in a process they would have to have wholly > disjoint memory, at which point the only sane long-term implementation > is separate processes and the management moves up a level anyway. > > That said, there are surely cases in which it might be convenient to > use at a per-thread level to correct a specific performance anomaly. > But at that point, you have certainly reached the level of hammer that > you can coordinate with an external daemon if necessary. So, I'm not super familiar with all the use cases but the whole cache allocation thing is almost by nature a specific niche thing and I feel pretty reluctant to blow off per-thread usages as too niche to worry about. > > I don't follow what you're trying to way with the above paragraph. > > Are you still talking about CAT? If so, that use case isn't the only > > one. I'm pretty sure there are people who would want to configure > > cache allocation at thread level. > > I'm not agreeing with you that "in cgroups" means "must be usable by > applications within that hierarchy". A cgroup subsystem used as a > partitioning API only by system management daemons is entirely > reasonable. CAT is a reasonable example of this. I see. The same argument. I don't think CAT just being system management thing makes sense. > > So, this is a trade-off we're consciously making. If there are > > common-enough use cases which require jumping across different cgroup > > domains, we'll try to figure out a way to accomodate those but by > > default migration is a very cold and expensive path. > > The core here was the need for allowing sub-process migration. I'm > not sure I follow the performance trade-off argument; haven't we > historically seen the opposite? That migration has been a slow-path > without optimizations and people pushing to make it faster? This > seems a hard generalization to make for something that's inherently > tied to a particular controller. It isn't something tied to a particular controller. Some controllers may get impacted less by than others but there's an inherent connection between how dynamic an association is and how expensive the locking around it needs to be and we need to set up basic behavior and usage conventions so that different controllers are designed and implemented assuming similar usage patterns; otherwise, we end up with the chaotic shit show that we have had where everything behaves differently and nobody knows what's the right way to do things and we end up locked into weird requirements which some controller induced for no good reason but cause significant pain on use cases which actually matter. > I don't care if we try turning that dial back to assume it's a cold > path once more, only that it's supported. It has always been a cold path and I'm not saying this is gonna be noticeably worse in the future but usages like bouncing threads on request-by-request basis are and will be clearly worse than bouncing to threads which are already in the target domain. > >> > A forwarding /proc/thread_self/cgroup accessor, or similar, would be another > >> > way to address some of these issues. > > > > That sounds horrible to me. What if the process wants to do RMW a > > config? > > Locking within a process is easy. It's not contained in the process at all. What if an external entity decides to migrate the process into another cgroup inbetween? > > What if the permissions are different after an intervening > > migration? > > This is a side-effect of migration not being properly supported. > > > What if the sub-hierarchy no longer exists or has been > > replaced by a hierarchy with the same topology but actualy is a > > different one? > > The easy answer is that: Only a process should be managing its > sub-hierarchy. That's the nice thing about hierarchies. cgroupfs is a horrible place to implement that part of interface. It doesn't make any sense to combine those two into the same hierarchy. You're agreeing to the identified problem but somehow still suggesting doing what we've been doing when the root cause of the said problem is conflating and interlocking these two separate things. > The harder answer is: How do we handle non-fungible resources such as > CPU assignments within a hierarchy? This is a big part of why I make > arguments for certain partitions being management-software only above. > This is imperfect, but better then where we stand today. I'm not following. Why is that different? > > Let's build an API which actually looks and behaves like an API which > > is properly isolated from what external agents may do to the process. > > I can't see how that would be "back to where we are today". All of > > those are pretty critical attributes for a public kernel API and > > utterly broken right now. > > Sure, but I don't think you can throw out per-thread control for all > controllers to enable this. Which makes everything else harder. A > intermediary step in unification might be that we move from N mounts > to 2. Those that can be managed at the process level, and those that > can't. It's a compromise, but may allow cleaner abstractions for the > former case. The transition can already be gradual. Why would you add yet another transition step? 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]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-08-24 17:50 +0200 |
| Message-ID | <q12au-3Av-11@gated-at.bofh.it> |
| In reply to | #1211496 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-08-22 14:29, Tejun Heo wrote: > Hello, Paul. > > On Fri, Aug 21, 2015 at 12:26:30PM -0700, Paul Turner wrote: > ... >> A very concrete example of the above is a virtual machine in which you >> want to guarantee scheduling for the vCPU threads which must schedule >> beside many hypervisor support threads. A hierarchy is the only way >> to fix the ratio at which these compete. > > Just to learn more, what sort of hypervisor support threads are we > talking about? They would have to consume considerable amount of cpu > cycles for problems like this to be relevant and be dynamic in numbers > in a way which letting them competing against vcpus makes sense. Do > IO helpers meet these criteria? > Depending on the configuration, yes they can. VirtualBox has some rather CPU intensive threads that aren't vCPU threads (their emulated APIC thread immediately comes to mind), and so does QEMU depending on the emulated hardware configuration (it gets more noticeable when the disk images are stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is pretty typical usage for large virtualization deployments). I've seen cases first hand where the vCPU's can make no reasonable progress because they are constantly getting crowded out by other threads. The use of the term 'hypervisor support threads' for this is probably not the best way of describing the contention, as it's almost always a full system virtualization issue, and the contending threads are usually storage back-end access threads. I would argue that there are better ways to deal properly with this (Isolate the non vCPU threads on separate physical CPU's from the hardware emulation threads), but such methods require large systems to be practical at any scale, and many people don't have the budget for such large systems, and this way of doing things is much more flexible for small scale use cases (for example, someone running one or two VM's on a laptop under QEMU or VirtualBox).
[toc] | [prev] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-24 19:10 +0200 |
| Message-ID | <q13pV-5xE-21@gated-at.bofh.it> |
| In reply to | #1212320 |
Hello, Austin. On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote: > >Just to learn more, what sort of hypervisor support threads are we > >talking about? They would have to consume considerable amount of cpu > >cycles for problems like this to be relevant and be dynamic in numbers > >in a way which letting them competing against vcpus makes sense. Do > >IO helpers meet these criteria? > > > Depending on the configuration, yes they can. VirtualBox has some rather > CPU intensive threads that aren't vCPU threads (their emulated APIC thread > immediately comes to mind), and so does QEMU depending on the emulated And the number of those threads fluctuate widely and dynamically? > hardware configuration (it gets more noticeable when the disk images are > stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is > pretty typical usage for large virtualization deployments). I've seen cases > first hand where the vCPU's can make no reasonable progress because they are > constantly getting crowded out by other threads. That alone doesn't require hierarchical resource distribution tho. Setting nice levels reasonably is likely to alleviate most of the problem. > The use of the term 'hypervisor support threads' for this is probably not > the best way of describing the contention, as it's almost always a full > system virtualization issue, and the contending threads are usually storage > back-end access threads. > > I would argue that there are better ways to deal properly with this (Isolate > the non vCPU threads on separate physical CPU's from the hardware emulation > threads), but such methods require large systems to be practical at any > scale, and many people don't have the budget for such large systems, and > this way of doing things is much more flexible for small scale use cases > (for example, someone running one or two VM's on a laptop under QEMU or > VirtualBox). I don't know. "Someone running one or two VM's on a laptop under QEMU" doesn't really sound like the use case which absolutely requires hierarchical cpu cycle distribution. 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]
| From | Mike Galbraith <umgwanakikbuti@gmail.com> |
|---|---|
| Date | 2015-08-24 21:30 +0200 |
| Message-ID | <q15Bo-gI-23@gated-at.bofh.it> |
| In reply to | #1212355 |
On Mon, 2015-08-24 at 13:04 -0400, Tejun Heo wrote: > Hello, Austin. > > On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote: > > >Just to learn more, what sort of hypervisor support threads are we > > >talking about? They would have to consume considerable amount of cpu > > >cycles for problems like this to be relevant and be dynamic in numbers > > >in a way which letting them competing against vcpus makes sense. Do > > >IO helpers meet these criteria? > > > > > Depending on the configuration, yes they can. VirtualBox has some rather > > CPU intensive threads that aren't vCPU threads (their emulated APIC thread > > immediately comes to mind), and so does QEMU depending on the emulated > > And the number of those threads fluctuate widely and dynamically? > > > hardware configuration (it gets more noticeable when the disk images are > > stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is > > pretty typical usage for large virtualization deployments). I've seen cases > > first hand where the vCPU's can make no reasonable progress because they are > > constantly getting crowded out by other threads. Hm. Serious CPU starvation would seem to require quite a few hungry threads, but even a few IO threads with kick butt hardware under them could easily tilt fairness heavily in favor of VPUs generating IO. > That alone doesn't require hierarchical resource distribution tho. > Setting nice levels reasonably is likely to alleviate most of the > problem. Unless the CPU controller is in use. -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]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-08-24 22:10 +0200 |
| Message-ID | <q16e6-1hz-17@gated-at.bofh.it> |
| In reply to | #1212355 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-08-24 13:04, Tejun Heo wrote: > Hello, Austin. > > On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote: >>> Just to learn more, what sort of hypervisor support threads are we >>> talking about? They would have to consume considerable amount of cpu >>> cycles for problems like this to be relevant and be dynamic in numbers >>> in a way which letting them competing against vcpus makes sense. Do >>> IO helpers meet these criteria? >>> >> Depending on the configuration, yes they can. VirtualBox has some rather >> CPU intensive threads that aren't vCPU threads (their emulated APIC thread >> immediately comes to mind), and so does QEMU depending on the emulated > > And the number of those threads fluctuate widely and dynamically? It depends, usually there isn't dynamic fluctuation unless there is a lot of hot[un]plugging of virtual devices going on (which can be the case for situations with tight host/guest integration), but the number of threads can vary widely between configurations (most of the VM's I run under QEMU have about 16 threads on average, but I've seen instances with more than 100 threads). The most likely case to cause wide and dynamic fluctuations of threads would be systems set up to dynamically hot[un]plug vCPU's based on system load (such systems have other issues to contend with also, but they do exist). >> hardware configuration (it gets more noticeable when the disk images are >> stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is >> pretty typical usage for large virtualization deployments). I've seen cases >> first hand where the vCPU's can make no reasonable progress because they are >> constantly getting crowded out by other threads. > > That alone doesn't require hierarchical resource distribution tho. > Setting nice levels reasonably is likely to alleviate most of the > problem. In the cases I've dealt with this myself, nice levels didn't cut it, and I had to resort to SCHED_RR with particular care to avoid priority inversions. >> The use of the term 'hypervisor support threads' for this is probably not >> the best way of describing the contention, as it's almost always a full >> system virtualization issue, and the contending threads are usually storage >> back-end access threads. >> >> I would argue that there are better ways to deal properly with this (Isolate >> the non vCPU threads on separate physical CPU's from the hardware emulation >> threads), but such methods require large systems to be practical at any >> scale, and many people don't have the budget for such large systems, and >> this way of doing things is much more flexible for small scale use cases >> (for example, someone running one or two VM's on a laptop under QEMU or >> VirtualBox). > > I don't know. "Someone running one or two VM's on a laptop under > QEMU" doesn't really sound like the use case which absolutely requires > hierarchical cpu cycle distribution. It depends on the use case. I never have more than 2 VM's running on my laptop (always under QEMU, setting up Xen is kind of pointless ona quad core system with only 8G of RAM), and I take extensive advantage of the cpu cgroup to partition resources among various services on the host.
[toc] | [prev] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2015-08-24 22:30 +0200 |
| Message-ID | <q16xs-1Fh-39@gated-at.bofh.it> |
| In reply to | #1212467 |
Hello, Austin. On Mon, Aug 24, 2015 at 04:00:49PM -0400, Austin S Hemmelgarn wrote: > >That alone doesn't require hierarchical resource distribution tho. > >Setting nice levels reasonably is likely to alleviate most of the > >problem. > > In the cases I've dealt with this myself, nice levels didn't cut it, and I > had to resort to SCHED_RR with particular care to avoid priority inversions. I wonder why. The difference between -20 and 20 is around 2500x in terms of weight. That should have been enough for expressing whatever precedence the vcpus should have over other threads. > >I don't know. "Someone running one or two VM's on a laptop under > >QEMU" doesn't really sound like the use case which absolutely requires > >hierarchical cpu cycle distribution. > > It depends on the use case. I never have more than 2 VM's running on my > laptop (always under QEMU, setting up Xen is kind of pointless ona quad core > system with only 8G of RAM), and I take extensive advantage of the cpu > cgroup to partition resources among various services on the host. Hmmm... I'm trying to understand the usecases where having hierarchy inside a process are actually required so that we don't end up doing something complex unnecessarily. So far, it looks like an easy alternative for qemu would be teaching it to manage priorities of its threads given that the threads are mostly static - vcpus going up and down are explicit operations which can trigger priority adjustments if necessary, which is unlikely to begin with. 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]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.kernel
csiph-web