On 2011-06-16 17:24, Alexandre Raymond wrote:
> Hi Jan,
>
> On Thu, Jun 16, 2011 at 5:31 AM, Jan Kiszka wrote:
>> Ingo Molnar pointed out that sending the timer signal to the whole
>> process, just blocking it everywhere, is suboptimal with an increasing
>> number of threads. QEMU is using this p
Hi Jan,
On Thu, Jun 16, 2011 at 5:31 AM, Jan Kiszka wrote:
> Ingo Molnar pointed out that sending the timer signal to the whole
> process, just blocking it everywhere, is suboptimal with an increasing
> number of threads. QEMU is using this pattern so far.
I am not familiar with this code, but d
On 06/16/2011 02:31 AM, Jan Kiszka wrote:
> ev.sigev_value.sival_int = 0;
> -ev.sigev_notify = SIGEV_SIGNAL;
> ev.sigev_signo = SIGALRM;
> +#ifdef SIGEV_THREAD_ID
> +if (qemu_signalfd_available()) {
> +ev.sigev_notify = SIGEV_THREAD_ID;
> +ev._sigev_un._tid = qemu_
* Jan Kiszka wrote:
> Ingo Molnar pointed out that sending the timer signal to the whole
> process, just blocking it everywhere, is suboptimal with an increasing
> number of threads. QEMU is using this pattern so far.
>
> But Linux provides a (non-portable) way to restrict the signal to a
> sin
Ingo Molnar pointed out that sending the timer signal to the whole
process, just blocking it everywhere, is suboptimal with an increasing
number of threads. QEMU is using this pattern so far.
But Linux provides a (non-portable) way to restrict the signal to a
single thread: Use SIGEV_THREAD_ID unl