Alan Cox wrote:
I just so happen to think we should implement a variety of CPU resource
limits beyond what we now do, so this, too, interests me.
Agreed - and make them all 64bit while doing the cleanup. One thing
several Unixen have we don't for 32bi boxes is a proper set of 64bit
resource han
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
On Tue, May 01, 2007 at 05:17:28PM -0700, Ulrich Drepper wrote:
> We have, in principal: setrlimit. We jump through hoops in the moment
> to make RLIMIT_CPU a per-process facility. This is all nice. All you
> need to do is to add resources RLIMIT_*_THREAD (e.g.,
> RLIMIT_CPU_THREAD) and addition
On 5/1/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
There are two ways of implementing this. One is to have the
JVM periodically poll using a pthread_getrusage() interface.
Not a good idea.
A better
choice might be some kind of per-thread CPU limit, that would result
in a thread-spec
At some point in the past, I wrote:
>> I just so happen to think we should implement a variety of CPU resource
>> limits beyond what we now do, so this, too, interests me.
On Wed, May 02, 2007 at 12:04:58AM +0100, Alan Cox wrote:
> Agreed - and make them all 64bit while doing the cleanup. One thin
> I just so happen to think we should implement a variety of CPU resource
> limits beyond what we now do, so this, too, interests me.
Agreed - and make them all 64bit while doing the cleanup. One thing
several Unixen have we don't for 32bi boxes is a proper set of 64bit
resource handling for memor
On Tue, May 01, 2007 at 06:27:24PM -0400, Theodore Tso wrote:
> There are two ways of implementing this. One is to have the
> JVM periodically poll using a pthread_getrusage() interface. A better
> choice might be some kind of per-thread CPU limit, that would result
> in a thread-specific S
On 5/1/07, Bill Irwin <[EMAIL PROTECTED]> wrote:
>> The basic
>> idea is to try to do it similarly to how everyone else does so userspace
>> (I suppose this would include glibc) don't have to bend over backward to
>> accommodate it. Or basically to do what everyone expects.
On Tue, May 01, 2007 at
On Tue, May 01, 2007 at 03:10:40PM -0700, Ulrich Drepper wrote:
> I think beside RUSAGE_THREAD you'll find no precedence. It's all new,
> you have to tread the path. The RUSAGE_THREAD interface is not
> sufficient, actually. First, if a thread terminates we don't have to
> keep it stick around u
On 5/1/07, Bill Irwin <[EMAIL PROTECTED]> wrote:
The basic
idea is to try to do it similarly to how everyone else does so userspace
(I suppose this would include glibc) don't have to bend over backward to
accommodate it. Or basically to do what everyone expects.
I think beside RUSAGE_THREAD you
On 5/1/07, Bill Irwin <[EMAIL PROTECTED]> wrote:
>> A sort of note for me to refer back to when I get the rest of the way
>> here. AIX does this with getrusage(RUSAGE_THREAD,...), Solaris with
>> getrusage(RUSAGE_LWP,...),
On Tue, May 01, 2007 at 11:39:46AM -0700, Ulrich Drepper wrote:
> RUSAGE_LW
On 5/1/07, Bill Irwin <[EMAIL PROTECTED]> wrote:
A sort of note for me to refer back to when I get the rest of the way
here. AIX does this with getrusage(RUSAGE_THREAD,...), Solaris with
getrusage(RUSAGE_LWP,...),
RUSAGE_LWP is a remnant of Solaris' M-on-N thread library days. No
reason to got
On Mon, Apr 09, 2007 at 04:53:15PM -0700, Andrew Morton wrote:
>> Seems sane. Could we please get it tested and get a full description in
>> place? Something which provides enough detail for the manpage maintainers.
>> Also, a quick comparison between Linux's RUSAGE_THREAD and $other-os's
>> impl
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>
> switch (who) {
> + case RUSAGE_THREAD:
> + utime = p->utime;
> + stime = p->stime;
> + r->ru_nvcsw = p->nvcsw;
> + r->ru_nivcsw = p->nivcsw;
> +
On Mon, 9 Apr 2007 18:12:57 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Mon, 9 Apr 2007 17:42:01 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
> wrote:
> >> My use for it is report generation in VM (and possibly other)
> >> testcases.
>
> On Mon, Apr 09, 2007 at 05:53:52PM -07
On Mon, 9 Apr 2007 17:42:01 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> My use for it is report generation in VM (and possibly other)
>> testcases.
On Mon, Apr 09, 2007 at 05:53:52PM -0700, Andrew Morton wrote:
> OK. The cool kids are using taskstats for this sort of thing now, bu
On Mon, 9 Apr 2007 17:42:01 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> My use for it is report generation in VM (and possibly other)
> testcases.
OK. The cool kids are using taskstats for this sort of thing now, but I
note that taskstats is inexplicably missing the context-switch
On Wed, 4 Apr 2007 11:10:50 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> Respun vs. 2.6.21-rc5-mm4, still untested. Also...
>> Signed-off-by: William Irwin <[EMAIL PROTECTED]>
[...]
On Mon, Apr 09, 2007 at 04:53:15PM -0700, Andrew Morton wrote:
> Seems sane. Could we please get it
On Wed, 4 Apr 2007 11:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Wed, 4 Apr 2007 10:29:31 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
> wrote:
> >> It is not now possible for a thread to retrieve its own rusage in
> >> isolation. Its rusage is nowhere exposed without be
On Wed, 04 Apr 2007 10:29:31 PDT, William Lee Irwin III said:
>> Index: anon/include/linux/resource.h
>> ===
>> --- anon.orig/include/linux/resource.h 2007-04-04 09:57:41.239118534
>> 0700
>> +++ anon/include/linux/resource.h
On Wed, 04 Apr 2007 10:29:31 PDT, William Lee Irwin III said:
> Index: anon/include/linux/resource.h
> ===
> --- anon.orig/include/linux/resource.h2007-04-04 09:57:41.239118534 -
0700
> +++ anon/include/linux/resource.h 20
On Wed, 4 Apr 2007 10:29:31 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> It is not now possible for a thread to retrieve its own rusage in
>> isolation. Its rusage is nowhere exposed without being intermixed with
>> that of its sibling threads. This patch adds support for an
>> RUSAGE
On Wed, 4 Apr 2007 10:29:31 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> It is not now possible for a thread to retrieve its own rusage in
> isolation. Its rusage is nowhere exposed without being intermixed with
> that of its sibling threads. This patch adds support for an
> RUSAGE_THR
It is not now possible for a thread to retrieve its own rusage in
isolation. Its rusage is nowhere exposed without being intermixed with
that of its sibling threads. This patch adds support for an
RUSAGE_THREAD who argument that returns rusage for only the desired
thread.
Untested.
-- wli
Inde
24 matches
Mail list logo
