Date: Tue, 29 May 2007 12:04:47 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "John Baldwin" <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. Message-ID: <b1fa29170705291204t76b9eb95jb6e391c3145455d2@mail.gmail.com> 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
> 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. Processes can certainly make numerous system calls within a single time slice. However, in userret it would be protected by a per process or per thread blocking mutex as opposed to a global spin mutex. It would be surprising if it isn't a net win, although it is quite possible that on a 2-way system the extra locking could have an adverse effect on some workloads. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170705291204t76b9eb95jb6e391c3145455d2>