Re: per-thread rusage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/1/07, Theodore Tso <[email protected]> wrote:
The question is should we use setrlimit() to set the per-thread CPU
limit, given that we would need some separate interface to set signal
that should be sent.

Is there any reason why we should have the interface specify whether
the signal should be directed to a specified process or kernel
thread-id, perhaps using si_pid field in the siginfo_t to specify
which thread had exceeded its CPU limit.  Or would this be overkill?

The more I think about it the more complex it gets.  There is a
problem with delivering the signal to the receiving process itself: it
is out of time and cannot perform the cleanup operation anymore.  You
could grant it a grace period but how long should that be?  Some of
the cleanup handlers might take a long time.  If you don't enforce the
CPU limit then it doesn't have to be in the kernel and you might as
well use CLOCK_THREAD_CPUTIME_ID and create a timer.  This should
already work today.  If not it must be fixed.

Delivering the timeout signal to another thread isn't really possible
either since the cleanup code might access thread-local data which
wouldn't work since it's not the canceled thread's data which is
accessed.

I don't have a good answer right now whether enforced CPU limits can
be implemented at all.  But it seems for your purposes a timer with
the CPU clock might be sufficient.


Do you think this is something that we could get standardized into an
upcoming Posix/Posix Threads standard?

Regardless of whether a solution can be found, it's too late for the
next revision.  The deadline for new features is long gone by.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux