Re: posix-cpu-timers revamp

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@xxxxxxxxxx>
Google, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: posix-cpu-timers revamp
    ... Tests with a process CPU timer set for a long expiration time. ... interval as set by setitimer. ... the first time it fires at the value set by setitimerbut from then on ... The current value of an itimer is a user feature, ...
    (Linux-Kernel)
  • Re: HR timers prevent an itimer from generating EINTR?
    ... In my test program I have a High Resolution timer firing every one ... I then execute a blocking system call (flock ... in this case) and expect the three second itimer to interrupt the system ... but it will not interrupt the blocking system call. ...
    (Linux-Kernel)
  • Re: itimer oddness in 2.6.12
    ... >>timestamp on an itimer and it expects the signal to be delivered at roughly ... actual interval retrieved by getitimer to set a global timer delta. ... it updates the notion of the current time by the timer delta. ...
    (Linux-Kernel)
  • Re: Anyone got a Class 101 for the Implements statement? (VB6)
    ... If you make a class that implements ITimer, the HiRes code will work with it ... in the HiRes Timer stuff* it's in the *test form* where the ... interface is implemented! ...
    (microsoft.public.vb.general.discussion)