Date: Tue, 29 May 2007 13:45:41 -0700 From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. Message-ID: <465C90F5.1000906@elischer.org> In-Reply-To: <20070529121653.P661@10.0.0.1> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?465C90F5.1000906>