Re: posix-cpu-timers revamp

Frank Mayhar
2008-03-24T17:35:32Z

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?