Re: rusage breakdown and cpu limits.

Jeff Roberson wrote:

On Tue, 29 May 2007, John Baldwin wrote:

On Tuesday 29 May 2007 02:01:36 pm Jeff Roberson wrote:
I'm working with Attilio to break down rusage further to be per-thread in
places where it is protected by the global scheduler lock. To support
this, I am interested in moving the rlimit cpulimit check into userret(),
or perhaps ast(). Is there any reason why we need to check this on every
context switch? Any objections to moving it? Eventually it will require
a different lock from the one we obtain to call mi_switch().

I think using a per-process spin lock (or a pool of spin locks) would be a
good first step. I wouldn't do anything more complicated unless the simple
approach doesn't work. The only reason to not move the check into userret()
would be if one is worried about threads chewing up CPU time while they are
in the kernel w/o bouncing out to userland. Also, it matters which one
happens more often (userret() vs mi_switch()). If on average threads perform
multiple system calls during a single time slice (no idea if this is true or
not), then moving the check to userret() would actually hurt performance.

The problem with using a pool or per-process spinlock is that it keeps the contention in the process domain, rather than thread domain. For multithreaded processes this will give the same contention as a global scheduler lock, only slightly reduced in scope. I'd like to solve this in such a way that we don't have to revisit it again.

I think I'm going to make the rusage struct per-thread and aggregate it on demand. There will be a lot of code churn, but it will be simple. There are a few cases where which will be complicated, and cpulimit is one of them.

So, there should be somewhere to store the aggregated stats from threads that have already exited.


Jeff


--
John Baldwin

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: rusage breakdown and cpu limits.
    ... places where it is protected by the global scheduler lock. ... To support ... this, I am interested in moving the rlimit cpulimit check into userret, ... Any objections to moving it? ...
    (freebsd-arch)
  • rusage breakdown and cpu limits.
    ... I'm working with Attilio to break down rusage further to be per-thread in places where it is protected by the global scheduler lock. ... To support this, I am interested in moving the rlimit cpulimit check into userret, or perhaps ast. ...
    (freebsd-arch)
  • Re: rusage breakdown and cpu limits.
    ... On Tue, 29 May 2007, John Baldwin wrote: ... Any objections to moving it? ... The only reason to not move the check into userret() ... For multithreaded processes this will give the same contention as a global scheduler lock, ...
    (freebsd-arch)
  • Re: rusage breakdown and cpu limits.
    ... places where it is protected by the global scheduler lock. ... this, I am interested in moving the rlimit cpulimit check into userret(), ... or perhaps ast(). ... Any objections to moving it? ...
    (freebsd-arch)