Date: Tue, 29 May 2007 12:19:33 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. Message-ID: <20070529121653.P661@10.0.0.1> In-Reply-To: <200705291456.38515.jhb@freebsd.org> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Jeff > > -- > John Baldwin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070529121653.P661>