On 2015-11-15 08:36, Aleksa Sarai wrote:
If so, could you share little more insight on how that time measure
outside of the cpu's cgroup cycles? Just so that its helpful to wider
audience.
Well, there are a number of things that I can think of that the kernel does
on behalf of processes that ca
>> If so, could you share little more insight on how that time measure
>> outside of the cpu's cgroup cycles? Just so that its helpful to wider
>> audience.
>
> Well, there are a number of things that I can think of that the kernel does
> on behalf of processes that can consume processor time that
On 2015-11-10 11:19, Parav Pandit wrote:
On Tue, Nov 10, 2015 at 9:28 PM, Austin S Hemmelgarn
wrote:
On 2015-11-10 10:25, Aleksa Sarai wrote:
Processes don't "use up resources" after they've died and been freed
(which is dealt with inside PIDs). Yes, lots of small processes that
die quickly c
On 2015/11/10 18:29, Tejun Heo wrote:
> It's not a stateful resource. Of course the resource is controlled in
> terms of bandwidth not absoulte amount consumed.
I'm glad we now agree on the basic facts.
> It's absurd to limit absoulte amount for CPU cycles.
And yet there's an "absurd" feature
On Tue, Nov 10, 2015 at 06:06:12PM +0100, Max Kellermann wrote:
> No, Tejun, the "cpu" controller does not do what my feature does: like
> I said, it only changes the priority, or let's rephrase (to account
> for the "absolute CPU cycle bandwith" thing): it changes the amount of
> CPU cycles a proc
On 2015/11/10 16:44, Tejun Heo wrote:
> On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote:
> > There's "cpu" which changes priority
>
> The cpu controller can limit both in terms of relative weight and
> absolute CPU cycle bandwidth.
No, Tejun, the "cpu" controller does not do what
On Tue, Nov 10, 2015 at 9:28 PM, Austin S Hemmelgarn
wrote:
> On 2015-11-10 10:25, Aleksa Sarai wrote:
>>
>> Processes don't "use up resources" after they've died and been freed
>> (which is dealt with inside PIDs). Yes, lots of small processes that
>> die quickly could (in principle) make hard wo
On 2015/11/10 16:25, Aleksa Sarai wrote:
> > The goal of this limit is to have another safeguard against fork
> > bombs. It gives processes a chance to set up their child processes /
> > threads, but will be stopped once they attempt to waste resources by
> > continuously exiting and cloning new
On 2015-11-10 10:25, Aleksa Sarai wrote:
Processes don't "use up resources" after they've died and been freed
(which is dealt with inside PIDs). Yes, lots of small processes that
die quickly could (in principle) make hard work for the scheduler, but
I don't see how "time spent scheduling in gener
Hello, Max.
On Tue, Nov 10, 2015 at 04:37:46PM +0100, Max Kellermann wrote:
> > But what's the resource here?
>
> CPU consumption and memory bandwidth. A fork/clone is an operation
Both are abstracted as CPU usage and controlled by the cpu controller.
> that puts considerable load on a machine
On 2015/11/10 16:12, Tejun Heo wrote:
> On Tue, Nov 10, 2015 at 03:06:46PM +0100, Max Kellermann wrote:
> > This patch introduces a new setting called "fork_remaining". When
> > positive, each successful fork decrements the value, and once it
> > reaches zero, no further forking is allowed, no ma
Hi Max,
I agree with what Tejun said, I just wanted to make a few specific points:
> This patch introduces a new setting called "fork_remaining". When
> positive, each successful fork decrements the value, and once it
> reaches zero, no further forking is allowed, no matter how many of
> those p
On Tue, Nov 10, 2015 at 03:06:46PM +0100, Max Kellermann wrote:
> This patch introduces a new setting called "fork_remaining". When
> positive, each successful fork decrements the value, and once it
> reaches zero, no further forking is allowed, no matter how many of
> those processes are still al
This patch introduces a new setting called "fork_remaining". When
positive, each successful fork decrements the value, and once it
reaches zero, no further forking is allowed, no matter how many of
those processes are still alive. The special value "unlimited"
disables the fork limit.
The goal o
14 matches
Mail list logo
