Messages in this thread | | | Subject | Re: posix-cpu-timers revamp | From | Frank Mayhar <> | Date | Mon, 24 Mar 2008 10:34:39 -0700 |
| |
On Sat, 2008-03-22 at 14:58 -0700, Roland McGrath wrote: > > I would really like to just ignore the 2-cpu scenario and just have two > > versions, the UP version and the n-way SMP version. It would make life, > > and maintenance, simpler. > Like I've said, it's only something to investigate for best performance. > If the conditional code is encapsulated well, it will be simple to add > another variant later and experiment with it.
Well, if it's acceptable, for a first cut (and the patch I'll submit), I'll handle the UP and SMP cases, encapsulating them in sched.h in such a way as to make it invisible (as much as is possible) to the rest of the code.
> There are several important scenarios you did not test. > Analysis of combinations of all these variables is needed. > 1. Tests with a few threads, like as many threads as CPUs or only 2x as many.
I've actually done this, although I didn't find the numbers particularly interesting. I'll do it again and keep the numbers, though.
> 2. Tests with a process CPU timer set for a long expiration time. > i.e. a timer set, but that never goes off in your entire run. > (This is what a non-infinity RLIMIT_CPU limit does.) > With the old code, a long enough timer and a small enough number > of threads will never trigger a "rebalance".
I'll do this at some point.
> > I guess I could be wrong about this, but it appears to be what the code > > is doing. If my analysis is correct, I really don't need a new field, > > since the old fields work just fine. > > The analysis above is correct but your conclusion here is wrong. > The current value of an itimer is a user feature, not just a piece > of internal bookkeeping.
After looking at the code again, I now understand what you're talking about. You overloaded it_*_expires to support both the POSIX interval timers and RLIMIT_CPU. So the way I have things, setting one can stomp the other.
> Your code causes any timer_settime or timer_delete call on a process > CPU timer or any setrlimit call on RLIMIT_CPU to suddenly change the > itimer setting just as if the user had made some setitimer call that > was never made or intended. That's wrong.
Right, because the original effect was to only set the it_*_expires on each individual task struct, leaving the one in the signal struct alone.
Might it be cleaner to handle the RLIMIT_CPU stuff separately, rather than rolling it into the itimer handling? -- Frank Mayhar <fmayhar@google.com> Google, Inc.
| |