On Tue, 25.06.13 08:31, Brian Bockelman (bbock...@cse.unl.edu) wrote:
>
> On Jun 25, 2013, at 4:56 AM, Lennart Poettering
> 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 you
On Jun 25, 2013, at 4:56 AM, Lennart Poettering 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. Do you envision
On Jun 25, 2013 2:43 AM, "Lennart Poettering"
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
> > wrote:
> > > On Mon, 24.06.13 16:01, Andy Lutomirski (l...@amacapital.net) wrote:
> > >
> > >> AFAICT the
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 y
On Mon, 24.06.13 17:09, Andy Lutomirski (l...@amacapital.net) wrote:
>
> On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering
> 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 whi
Lennart Poettering 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 logi
On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering
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 seems like that
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 us
On Mon, Jun 24, 2013 at 4:40 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Jun 24, 2013 at 4:38 PM, Andy Lutomirski 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
Hello,
On Mon, Jun 24, 2013 at 4:38 PM, Andy Lutomirski 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 use multiple hier
On Mon, Jun 24, 2013 at 4:37 PM, Tejun Heo 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 a reas
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 a reasonably large subset of cgroup functionality. If the
> sing
On Mon, Jun 24, 2013 at 4:19 PM, Tejun Heo 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 part doesn
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 indivi
On Mon, Jun 24, 2013 at 12:37 PM, Tejun Heo 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.
>
> Hmm..
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:10 PM, Tejun Heo 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 case
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 fo
On Mon, Jun 24, 2013 at 11:38 AM, Tejun Heo wrote:
> 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 rea
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
> > exa
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
> >
On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering
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 we recommend other use
On Mon, Jun 24, 2013 at 6:27 AM, Lennart Poettering
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 fine-grained things
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 i
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 wha
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 sy
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 cgro
On Fri, Jun 21, 2013 at 3:07 PM, Kay Sievers wrote:
> On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H
> 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 th
On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H
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 probably be some bus cal
On Fri, Jun 21, 2013 at 2:17 PM, Lennart Poettering
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 its own cpu
>> >
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 sho
On Fri, Jun 21, 2013 at 1:10 PM, Lennart Poettering
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 for doing
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
On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering
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 forward to seeing t
34 matches
Mail list logo
