Re: [RFC][PATCH 0/1] MAZE: Mazed processes monitor

From: Hirofumi Nakagawa
Date: Thu May 22 2008 - 05:37:15 EST


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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/