On Tue, 25.06.13 08:31, Brian Bockelman (bbock...@cse.unl.edu) wrote:
On Jun 25, 2013, at 4:56 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Tue, 25.06.13 02:21, Brian Bockelman (bbock...@cse.unl.edu) wrote:
A few questions came to mind which may provide interesting input
On Jun 25, 2013, at 4:56 AM, Lennart Poettering lenn...@poettering.net wrote:
On Tue, 25.06.13 02:21, Brian Bockelman (bbock...@cse.unl.edu) wrote:
A few questions came to mind which may provide interesting input
to your design process:
1) I use cgroups heavily for resource accounting.
On Mon, 24.06.13 17:09, Andy Lutomirski (l...@amacapital.net) wrote:
On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net) wrote:
AFAICT the main reason that systemd uses cgroup is to efficiently
On Tue, 25.06.13 02:21, Brian Bockelman (bbock...@cse.unl.edu) wrote:
A few questions came to mind which may provide interesting input
to your design process:
1) I use cgroups heavily for resource accounting. Do you envision
me querying via dbus for each accounting attribute? Or do you
On Jun 25, 2013 2:43 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Mon, 24.06.13 17:09, Andy Lutomirski (l...@amacapital.net) wrote:
On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net)
On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote:
1. I put all the entire world into a separate, highly constrained
cgroup. My real-time code runs outside that cgroup. This seems to
exactly what slices are for, but I need kernel threads to go in to
the constrained cgroup.
On Fri, 21.06.13 14:47, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
Do you suggest these manipulations should be implemented without high
level systemd API's and the controller just manipulates the cgroups
directly?
All changes to cgroup attributes must go through systemd. If the
On Mon, Jun 24, 2013 at 03:27:15PM +0200, Lennart Poettering wrote:
On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote:
1. I put all the entire world into a separate, highly constrained
cgroup. My real-time code runs outside that cgroup. This seems to
exactly what
On 06/21/2013 10:36 AM, Lennart Poettering wrote:
2) This hierarchy becomes private property of systemd. systemd will set
it up. Systemd will maintain it. Systemd will rearrange it. Other
software that wants to make use of cgroups can do so only through
systemd's APIs. This single-writer logic
On Mon, Jun 24, 2013 at 6:27 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote:
2. I manage services and tasks outside systemd (for one thing, I
currently use Ubuntu, but even if I were on Fedora, I have a bunch
of
On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering
lenn...@poettering.net wrote:
As long as you only used the high-level options such as
CPUShares, MemoryLimit and so on you should be on the safe side.
This is already representative of how we're doing thing in large-scale
production and how
Hello,
On Mon, Jun 24, 2013 at 02:39:53PM +0100, Daniel P. Berrange wrote:
On Mon, Jun 24, 2013 at 03:27:15PM +0200, Lennart Poettering wrote:
On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote:
1. I put all the entire world into a separate, highly constrained
cgroup.
Hello,
On Mon, Jun 24, 2013 at 03:27:15PM +0200, Lennart Poettering wrote:
On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote:
1. I put all the entire world into a separate, highly constrained
cgroup. My real-time code runs outside that cgroup. This seems to
exactly
Hello, Andy.
On Mon, Jun 24, 2013 at 11:49:05AM -0700, Andy Lutomirski wrote:
I have an idea where it should be headed in the long term but am not
sure about short-term solution. Given that the only sort wide-spread
use case is virt kthreads, maybe it just needs to be special cased for
On Mon, Jun 24, 2013 at 12:10 PM, Tejun Heo t...@kernel.org wrote:
Hello, Andy.
On Mon, Jun 24, 2013 at 11:49:05AM -0700, Andy Lutomirski wrote:
I have an idea where it should be headed in the long term but am not
sure about short-term solution. Given that the only sort wide-spread
use
Hello,
On Mon, Jun 24, 2013 at 12:24:38PM -0700, Andy Lutomirski wrote:
Because more things are becoming per cpu without the option of moving
of per-cpu things on behalf of one cpu to another cpu. RCU is a nice
exception.
Hmm... but in most cases it's per-cpu on the same cpu that initiated
On Mon, Jun 24, 2013 at 12:37 PM, Tejun Heo t...@kernel.org wrote:
Hello,
On Mon, Jun 24, 2013 at 12:24:38PM -0700, Andy Lutomirski wrote:
Because more things are becoming per cpu without the option of moving
of per-cpu things on behalf of one cpu to another cpu. RCU is a nice
exception.
Hello,
On Mon, Jun 24, 2013 at 04:01:07PM -0700, Andy Lutomirski wrote:
So what is cgroup for? That is, what's the goal for what the new API
should be able to do?
It is a for controlling and distributing resources. That part doesn't
change. It's just not built to be used directly by
On Mon, Jun 24, 2013 at 4:19 PM, Tejun Heo t...@kernel.org wrote:
Hello,
On Mon, Jun 24, 2013 at 04:01:07PM -0700, Andy Lutomirski wrote:
So what is cgroup for? That is, what's the goal for what the new API
should be able to do?
It is a for controlling and distributing resources. That
On Mon, Jun 24, 2013 at 4:37 PM, Tejun Heo t...@kernel.org wrote:
Hello, Andy.
On Mon, Jun 24, 2013 at 04:27:17PM -0700, Andy Lutomirski wrote:
I guess what I'm trying to say here is that many systems will rather
fundamentally use systemd. Admins of those systems should still have
access to
Hello,
On Mon, Jun 24, 2013 at 4:38 PM, Andy Lutomirski l...@amacapital.net wrote:
Now I'm confused. I thought that support for multiple hierarchies was
going away. Is it here to stay after all?
It is going to be deprecated but also stay around for quite a while.
That said, I didn' t mean to
On Mon, Jun 24, 2013 at 4:40 PM, Tejun Heo t...@kernel.org wrote:
Hello,
On Mon, Jun 24, 2013 at 4:38 PM, Andy Lutomirski l...@amacapital.net wrote:
Now I'm confused. I thought that support for multiple hierarchies was
going away. Is it here to stay after all?
It is going to be deprecated
On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net) wrote:
AFAICT the main reason that systemd uses cgroup is to efficiently
track which service various processes came from and to send signals,
and it seems like that use case could be handled without cgroups at
all by creative use
On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net) wrote:
AFAICT the main reason that systemd uses cgroup is to efficiently
track which service various processes came from and to send signals,
and it
Lennart Poettering lennart at poettering.net writes:
2) This hierarchy becomes private property of systemd. systemd will set
it up. Systemd will maintain it. Systemd will rearrange it. Other
software that wants to make use of cgroups can do so only through
systemd's APIs. This single-writer
Heya,
On monday I posted this mail:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
Here's an update and a bit on the bigger picture:
Half of what I mentioned there is now in place. There's now a new
slice unit type in place in git, and everything is hooked up to
it.
On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering
lenn...@poettering.net wrote:
Heya,
On monday I posted this mail:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
Here's an update and a bit on the bigger picture:
Thanks for doing this - I am really looking
On Fri, 21.06.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
Here's an update and a bit on the bigger picture:
Thanks for doing this - I am really looking forward to seeing this all
take shape, and I
On Fri, Jun 21, 2013 at 1:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 21.06.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html
Here's an update and a bit on the bigger picture:
Thanks
On Fri, 21.06.13 14:10, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
So, in the future, when you have some service, and that service wants to
alter some cgroup resource limits for itself (let's say: set its own cpu
shares value to 1500), this is what should happen: the service should
On Fri, Jun 21, 2013 at 2:17 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 21.06.13 14:10, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
So, in the future, when you have some service, and that service wants to
alter some cgroup resource limits for itself (let's say: set
On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
Only userspace can distinguish between e.g. a foreground and
background application (WM) and decide that CPU consumption of certain
apps in the background is excessive, and throttle it down further,
This would
On Fri, Jun 21, 2013 at 3:07 PM, Kay Sievers k...@vrfy.org wrote:
On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
Only userspace can distinguish between e.g. a foreground and
background application (WM) and decide that CPU consumption of certain
apps in the
33 matches
Mail list logo
