Although I don't fully understand all the issues here,
I'm concerned about this proposal. In particular, our
garbage collector (used by gcj, and Mono, among others)
uses signals to stop threads for each garbage collection.
With a small heap, and many threads, I would expect the
frequency of signal delivery to be similar to what you
get with performance tools. But it does not, and should not,
use SIGPROF.
I think this is a more general issue. Special casing one
piece of it is only going to make performance more surprising,
something I think should be avoided if at all possible.
Hans
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Ray Bryant
> Sent: Monday, November 22, 2004 11:23 AM
> To: Andi Kleen
> Cc: Andreas Schwab; Kernel Mailing List; [email protected];
> lse-tech; [email protected]; Dean Roe; Brian Sumner; John Hawkes
> Subject: Re: [Lse-tech] scalability of signal delivery for
> Posix Threads
>
>
> OK, apparently SIGPROF is delivered in both the ITIMER_PROF and
> pmu interrupt cases, so if we special case that signal we should
> be fine.
> --
> Best Regards,
> Ray
> -----------------------------------------------
> Ray Bryant
> 512-453-9679 (work) 512-507-7807 (cell)
> [email protected] [email protected]
> The box said: "Requires Windows 98 or better",
> so I installed Linux.
> -----------------------------------------------
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-ia64" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> I think this is a more general issue. Special casing one
It just cannot be done in the general case without slowing
down sigaction significantly. Or maybe it can, but nobody
has proposed a way to do it so far.
It's difficult to design for machines where a simple spinlock
doesn't work properly anymore.
> piece of it is only going to make performance more surprising,
> something I think should be avoided if at all possible.
The special case in particular would be signals directed to a specific TID;
compared to signals load balanced over the thread group which needs
shared writable state. To simplify the fast path you could also make
more simplications: no queueing (otherwise you would need to duplicate
a lot of state to handle that into the task_struct) and probably
no SIGCHILD which is also full of special cases.
-And