Re: rusage breakdown and cpu limits.

On Tue, 29 May 2007, Kip Macy wrote:

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.

Not many more than a few hundred million syscalls can be made within a
timeslice of 100 mS. FreeBSD does too many context switches for
interrupts, so the number in practice seem to be mostly in the range of
1-10, but I hope for 100-1000.

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.

Any locking within userret() would be a good pessimization. There
are none now, but still a lot of bloat.

In this case, correct proc locking isn't even possible, since the
runtime update must occur while something like a global scheduler lock
is held. When a context switch occurs, the lock must protect at least
the old process and the new process, and somehow prevent interference
from other processes. The update of the runtime needs essentially the
same lock. Any locking in userret() would need to use the same lock
as the update to be perfectly correct. Fortunately, the cpulimit limit
check only needs to be correct to within seconds or even minutes. A
sloppy unlocked check don't often enough would work OK, at least if
you re-check with correct locking before killing the process.
Alternatively, the sloppiness can be due to delayed updates -- let the
rusage data lag by up to a second or so in the context of the check;
the runtime would accumulate accurately somewhere, but the check
wouldn't see it all the accumulation step would need the full lock
for reading and writing the scattered data and a lesser lock for
updating the accumulated data. userret() still shouldn't be pessimized
by acquiring the lesser lock.

I still think this misses the point -- the check is the easy part,
and can be done at no extra locking cost while the full lock is held.

Bruce
_______________________________________________
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: using clustered index to optimize inserts ...
    ... I will try to explain locking in terms of Sybase docs... ... Allpages Locking: Allpages locking locks both data pages and index ... the data page is locked with an exclusive lock. ... Clustered Index: The datarows will be arranged as per the clustered ...
    (comp.databases.sybase)
  • Re: CSingleLock - known behaviour?
    ... It is better to design code that doesn't require locking. ... If you don't need the resource, don't lock it. ... magnitude less efficient, than locking once. ...
    (microsoft.public.vc.mfc)
  • Re: Strange multi-user timing phenomenon
    ... table record with pessimistic locking and both edit the same record. ... the recordset will be sufficient to lock out other users. ... update the recordset (if you had to edit data) and then close it. ...
    (microsoft.public.access.formscoding)
  • Re: Strange multi-user timing phenomenon
    ... I tried your locking method using a perssimistic recordset and it appears to ... user places his lock and grabs the same record. ... I would try opening a fixed single-row recordset with pessimistic locking, ...
    (microsoft.public.access.formscoding)
  • [UNIX] File Locking Local Denial of Service (Sendmails Impact)
    ... Any application which uses either flockor fcntlstyle locking or ... Since this attack requires a user to use their own account to lock a file, ... process holds an exclusive lock on a file, no other process can obtain an ... File locking is used throughout Sendmail for a variety of files including ...
    (Securiteam)