From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: Jens Axboe <jens.axboe@oracle.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Tom Zanussi <tzanussi@gmail.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
righi.andrea@gmail.com
Subject: Re: [PATCH 2/3] relay: Fix race condition which occurs when reading across CPUs.
Date: Tue, 17 Jun 2008 17:55:35 +0300 [thread overview]
Message-ID: <20080617175535.638e54c5@linux360.ro> (raw)
In-Reply-To: <20080617135031.GA10316@Krystal>
On Tue, 17 Jun 2008 09:50:31 -0400
Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:
> Yeah, although using set affinity with CPU hotplug is broken by
> design.
>
> Mathieu
Never thought about this, but it does make sense. I presume this
affects relay reading as well, right? Quote from sched_setaffinity(2):
> EINVAL The affinity bit mask mask contains no processors that are phys-
> ically on the system, or cpusetsize is smaller than the size of
> the affinity mask used by the kernel.
We have 2 situations:
1. CPUs do _not_ get reordered --- the mask is then invalid, will it be
invalidated by the kernel even if set prior to the hotplug event?
2. CPUs get reordered after hotplug events. Assume this ([CPU logical <physical>]):
CPU 0 <0>, CPU 1 <1>, CPU 2 <2> => CPU 0 <0>, CPU 1 <2>
relay filenames likely change, but the underlying fds are preserved.
If the threads get migrated, this means we end up reading cross-CPU, AFAICS.
Do we ignore this and hope no one uses relay apps while triggering CPU
hotplug events?
Eduard
next prev parent reply other threads:[~2008-06-17 14:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 1:09 [PATCH 2/3] relay: Fix race condition which occurs when reading across CPUs Eduard - Gabriel Munteanu
2008-06-14 4:26 ` Tom Zanussi
2008-06-14 15:11 ` Eduard - Gabriel Munteanu
2008-06-14 16:16 ` Pekka Enberg
2008-06-16 5:38 ` Tom Zanussi
2008-06-16 6:19 ` Pekka Enberg
2008-06-17 4:52 ` Tom Zanussi
2008-06-16 12:22 ` Mathieu Desnoyers
2008-06-16 13:22 ` Eduard - Gabriel Munteanu
2008-06-16 16:46 ` Jens Axboe
2008-06-16 18:18 ` Pekka Enberg
2008-06-16 18:23 ` Mathieu Desnoyers
2008-06-16 18:28 ` Jens Axboe
2008-06-17 12:39 ` Eduard - Gabriel Munteanu
2008-06-17 12:49 ` Eduard - Gabriel Munteanu
2008-06-17 13:10 ` Mathieu Desnoyers
2008-06-17 13:35 ` Eduard - Gabriel Munteanu
2008-06-17 13:50 ` Mathieu Desnoyers
2008-06-17 14:55 ` Eduard - Gabriel Munteanu [this message]
2008-06-17 12:55 ` Mathieu Desnoyers
2008-06-17 13:21 ` Eduard - Gabriel Munteanu
-- strict thread matches above, loose matches on Subject: below --
2008-06-12 20:26 Eduard - Gabriel Munteanu
2008-06-12 22:58 ` Andrea Righi
2008-06-12 23:15 ` Eduard - Gabriel Munteanu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080617175535.638e54c5@linux360.ro \
--to=eduard.munteanu@linux360.ro \
--cc=akpm@linux-foundation.org \
--cc=compudj@krystal.dyndns.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=righi.andrea@gmail.com \
--cc=tzanussi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.