All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hirofumi Nakagawa <hnakagawa@miraclelinux.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [RFC][PATCH 0/1] MAZE: Mazed processes monitor
Date: Thu, 22 May 2008 18:31:25 +0900	[thread overview]
Message-ID: <48353D6D.8010603@miraclelinux.com> (raw)
In-Reply-To: <87y76d7w0n.fsf@basil.nowhere.org>

Hi Andi,

Thank you for your comment and proposal.

> How about you implement a way to change the RLIMIT_CPU limit
> of a running task (and possibly fix it to use a finer grained unit
> if you need <1s resolution).
>
> Then you could run a user space daemon running with lower priority that just regularly resets the RLIMIT_CPUs of all running processes.
>
> If some RT process uses so much time that the user daemon cannot
> keep up its cpu time limit will be eventually exceeded and it will
> be killed.
>
> I think that would be a far cleaner and generic way to implement
> this.
>
> -Andi

I also watch normal processes, which run into infinite loop but
cleanly scheduled out by sched when a time slice expires.
In this case, your deamon still can reset the counter.

> Isn't that very similar to RLIMIT_CPU? The main difference seems to be
> that they're regularly reset and that they can be more fine grained
> than seconds.

The differences with MAZE and rlimit are as follows.
  - MAZE detects excessive CPU cycle usage, but rlimits limits total amount
    of CPU usage.
    MAZE can safely handle CPU intensive but correctly running processes.

  - User processes can add watched processes in MAZE.

  - MAZE allows users to choose a way how to act on the process,
    selecting which signal to send.

Following example shows the differences of features MZE and rlimit

----
void foo(void)
{
     for(;;);
}
----
This code receives a signal shortly,
if registered under either rlimit or MAZE.

----
void foo(void)
{
     for(;;) {
         sleep(1);
     }
}
----
This code receives a signal in case of rlimit.
But, it doesn't receive a signal under MAZE.
There are cases when you need to distinguish these two types.

Thanks.
Hirofumi Nakagawa



      parent reply	other threads:[~2008-05-22  9:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-13 11:47 [RFC][PATCH 0/1] MAZE: Mazed processes monitor Hirofumi Nakagawa
2008-05-13 15:41 ` Andrew Morton
2008-05-22  9:31   ` Hirofumi Nakagawa
2008-05-13 21:07 ` Andi Kleen
2008-05-14 13:52   ` Hirofumi Nakagawa
2008-05-22  9:31   ` Hirofumi Nakagawa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48353D6D.8010603@miraclelinux.com \
    --to=hnakagawa@miraclelinux.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.