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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox