Hello,
On 15.6.2018 г. 22:07 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 08:40:02PM +0300, Ivan Zahariev wrote:
The lazy pids accounting + modern fast CPUs makes the "pids.current"
metric practically unusable for resource limiting in our case. For a
test, when we started and ended one single
Hello,
On 15.6.2018 г. 22:07 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 08:40:02PM +0300, Ivan Zahariev wrote:
The lazy pids accounting + modern fast CPUs makes the "pids.current"
metric practically unusable for resource limiting in our case. For a
test, when we started and ended one single
Hello, Ivan.
On Fri, Jun 15, 2018 at 08:40:02PM +0300, Ivan Zahariev wrote:
> The lazy pids accounting + modern fast CPUs makes the "pids.current"
> metric practically unusable for resource limiting in our case. For a
> test, when we started and ended one single process very quickly, we
> saw
Hello, Ivan.
On Fri, Jun 15, 2018 at 08:40:02PM +0300, Ivan Zahariev wrote:
> The lazy pids accounting + modern fast CPUs makes the "pids.current"
> metric practically unusable for resource limiting in our case. For a
> test, when we started and ended one single process very quickly, we
> saw
Hello,
On 15.6.2018 г. 19:16 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 07:07:27PM +0300, Ivan Zahariev wrote:
I understand all concerns and design decisions. However, having
RLIMIT_NPROC support combined with "cgroups" hierarchy would be very
handy.
Does it make sense that you introduce
Hello,
On 15.6.2018 г. 19:16 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 07:07:27PM +0300, Ivan Zahariev wrote:
I understand all concerns and design decisions. However, having
RLIMIT_NPROC support combined with "cgroups" hierarchy would be very
handy.
Does it make sense that you introduce
Hello,
On Fri, Jun 15, 2018 at 07:07:27PM +0300, Ivan Zahariev wrote:
> I understand all concerns and design decisions. However, having
> RLIMIT_NPROC support combined with "cgroups" hierarchy would be very
> handy.
>
> Does it make sense that you introduce "nproc.current" and
> "nproc.max"
Hello,
On Fri, Jun 15, 2018 at 07:07:27PM +0300, Ivan Zahariev wrote:
> I understand all concerns and design decisions. However, having
> RLIMIT_NPROC support combined with "cgroups" hierarchy would be very
> handy.
>
> Does it make sense that you introduce "nproc.current" and
> "nproc.max"
Hi,
Thank you for the quick and insightful reply. I have one suggestion below:
On 15.6.2018 г. 18:41 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
The standard RLIMIT_NPROC does not suffer from such accounting
discrepancies at any time.
They seem
Hi,
Thank you for the quick and insightful reply. I have one suggestion below:
On 15.6.2018 г. 18:41 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
The standard RLIMIT_NPROC does not suffer from such accounting
discrepancies at any time.
They seem
Hello,
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
> The standard RLIMIT_NPROC does not suffer from such accounting
> discrepancies at any time.
RLIMIT_NPROC uses a dedicated atomic counter which is updated when the
process is getting reaped; however, that doesn't actually
Hello,
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
> The standard RLIMIT_NPROC does not suffer from such accounting
> discrepancies at any time.
RLIMIT_NPROC uses a dedicated atomic counter which is updated when the
process is getting reaped; however, that doesn't actually
On 14.6.2018 г. 18:06 ч., Tejun Heo wrote:
On Thu, Jun 14, 2018 at 02:56:00PM +0300, Ivan Zahariev wrote:
I posted a kernel bug about this a month ago but it did not receive
any attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713
Here is a copy of the bug report and I hope that this
On 14.6.2018 г. 18:06 ч., Tejun Heo wrote:
On Thu, Jun 14, 2018 at 02:56:00PM +0300, Ivan Zahariev wrote:
I posted a kernel bug about this a month ago but it did not receive
any attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713
Here is a copy of the bug report and I hope that this
On 2018-06-15, Aleksa Sarai wrote:
> > I've tested this on 4.14.27 and 4.4.0-124-generic Ubuntu.
> >
> > If I start a couple of processes which exit very quickly (like a simple Bash
> > script with many commands in it), the reported value in "pids.current" is
> > not updated immediately when
On 2018-06-15, Aleksa Sarai wrote:
> > I've tested this on 4.14.27 and 4.4.0-124-generic Ubuntu.
> >
> > If I start a couple of processes which exit very quickly (like a simple Bash
> > script with many commands in it), the reported value in "pids.current" is
> > not updated immediately when
On 2018-06-14, Ivan Zahariev wrote:
> I posted a kernel bug about this a month ago but it did not receive any
> attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713
I believe that very few people watch the kernel bugzilla -- it's almost
always better to send a mail to LKML (speaking of
On 2018-06-14, Ivan Zahariev wrote:
> I posted a kernel bug about this a month ago but it did not receive any
> attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713
I believe that very few people watch the kernel bugzilla -- it's almost
always better to send a mail to LKML (speaking of
18 matches
Mail list logo
