Re: [Bugme-new] [Bug 9906] New: Weird hang with NPTL and SIGPROF.

Thanks for the detailed explanation and for bringing this to my attention.

This is a problem we knew about when I first implemented posix-cpu-timers
and process-wide SIGPROF/SIGVTALRM. I'm a little surprised it took this
long to become a problem in practice. I originally expected to have to
revisit it sooner than this, but I certainly haven't thought about it for
quite some time. I'd guess that HZ=1000 becoming common is what did it.

The obvious implementation for the process-wide clocks is to have the
tick interrupt increment shared utime/stime/sched_time fields in
signal_struct as well as the private task_struct fields. The all-threads
totals accumulate in the signal_struct fields, which would be atomic_t.
It's then trivial for the timer expiry checks to compare against those
totals.

The concern I had about this was multiple CPUs competing for the
signal_struct fields. (That is, several CPUs all running threads in the
same process.) If the ticks on each CPU are even close to synchronized,
then every single time all those CPUs will do an atomic_add on the same
word. I'm not any kind of expert on SMP and cache effects, but I know
this is bad. However bad it is, it's that bad all the time and however
few threads (down to 2) it's that bad for that many CPUs.

The implementation we have instead is obviously dismal for large numbers
of threads. I always figured we'd replace that with something based on
more sophisticated thinking about the CPU-clash issue.

I don't entirely follow your description of your patch. It sounds like it
should be two patches, though. The second of those patches (workqueue)
sounds like it could be an appropriate generic cleanup, or like it could
be a complication that might be unnecessary if we get a really good
solution to main issue.

The first patch I'm not sure whether I understand what you said or not.
Can you elaborate? Or just post the unfinished patch as illustration,
marking it as not for submission until you've finished.


Thanks,
Roland
--
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: page fault scalability patch V12 [0/7]: Overview and performance tests
    ... For more than 64 cpus the improvement in performace ... patches that performance was about doubled from 8 to 512 CPUS. ... these patches are basically only helpful to new ... The downside of my patch - well the main downsides - compared to yours ...
    (Linux-Kernel)
  • [PATCH sched-devel 7/7] cpuisol: Do not halt isolated CPUs with Stop Machine
    ... This patch makes "stop machine" ignore isolated CPUs. ... It addresses exact same usecase explained in the previous workqueue isolation patch. ...
    (Linux-Kernel)
  • Re: Undocumented and duplicated code
    ... see if duron support PAT. ... There must be some CPUs with the "pat" flag set but not being usable? ... places doesn't look good - this really deserved from the beginning being factored out into an own function to avoid future problems when CPUs get added (like what happens with your patch here - it touches only one place, and since the same context is present in two places in the same file "patch" might even choose freely where it gets applied...). ...
    (Linux-Kernel)
  • Re: [PATCH 1/2] boot: increase stack size for kernel boot loader decompressor
    ... I see you have applied the following patch to x86#for-akpm. ... I think you ment to use this one ... included but not your boot tweak. ... would you expect a real 4K CPUs system to boot any differently? ...
    (Linux-Kernel)
  • Re: [sched-devel, patch-rfc] rework of "prioritize non-migratable tasks over migratable
    ... I haven't had a chance to review your patch, so I am only responding to the comments in this thread. ... - there might have been other pending tasks (of equal prio) on this ... there are no other pending tasks on the queue that ... its affinity allows CPUs that can be used neither by ...
    (Linux-Kernel)