On Thu, Jun 20, 2013 at 9:15 PM, Lennart Poettering
wrote:
> On Wed, 19.06.13 13:36, Umut Tezduyar (u...@tezduyar.com) wrote:
>
>> Hi Lennart,
>>
>> I didn't quite understand how this could end up in a deadlock
>> (http://lists.freedesktop.org/archives/systemd-devel/2013-June/011404.html)
>
> Here
On Sat, Jun 22, 2013 at 3:34 PM, Jan Janssen wrote:
> ---
> src/udev/udev-rules.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.
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, 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 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 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 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 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
Exciting! You should post this to the systemd group on Google+.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
In our case, the issue wasn't kernel process creation; it was the CPU
and I/O overhead of service start-up. At some point, the system gets
dominated by context-switching, and throughput suffers. For example,
you certainly wouldn't want the box to go into swap because of
start-up allocation spikes.
On Mon, Jun 24, 2013 at 9:55 AM, David Strauss wrote:
> For example, you certainly wouldn't want the box to go into swap because of
> start-up allocation spikes.
I should clarify: that's not a context-switching example. It's just
another case where throttling might help.
--
David Strauss
| da
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
> >
Done and done, complete example (with amd64 container) here:
https://github.com/polvi/go-socket-activated-example
-Alex
On Mon, Jun 24, 2013 at 8:46 AM, David Strauss wrote:
> Exciting! You should post this to the systemd group on Google+.
___
syst
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
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, 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 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,
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 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 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 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, 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: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,
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: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
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: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
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
28 matches
Mail list logo
