From: Peter Zijlstra <peterz@infradead.org>
To: Gregory Haskins <ghaskins@novell.com>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 0/2][RFC] VFCIPI v3
Date: Tue, 31 Jul 2007 16:25:57 +0200 [thread overview]
Message-ID: <1185891957.12034.12.camel@twins> (raw)
In-Reply-To: <20070731132153.4790.37217.stgit@novell1.haskins.net>
Hi Gregory,
This patch set approaches the problem from the wrong angle (and has a
few problems due to that).
The idea to use a workqueue (or in your case workqueue-like) solution to
the problem is valid, however instead of re-using (and improving) the
current workqueue infrastructure, you re-implement it (with mistakes).
The solution currently in -rt uses regular workqueues to implement
schedule_on_each_cpu() - a drop in replacement for on_each_cpu() in the
context of -rt and useful outside of that if people do require such
functionality.
Your idea of using priority arrays in the workqueue is a good one,
please implement that for the regular workqueues.
Your idea that GFP_ATOMIC is broken in -rt is unfortunate, it isn't. The
whole allocator is preemptable - that is a feature!
Please keep up the good work, looking forward to those prio-workqueue
patches.
Peter
next prev parent reply other threads:[~2007-07-31 14:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 13:24 [PATCH 0/2][RFC] VFCIPI v3 Gregory Haskins
2007-07-31 13:24 ` [PATCH 1/2] RT: Preemptible Function-Call-IPI Support Gregory Haskins
2007-07-31 13:24 ` [PATCH 2/2] RT: Add priority inheritance to the VFCIPI facility Gregory Haskins
2007-07-31 14:25 ` Peter Zijlstra [this message]
2007-07-31 15:33 ` [PATCH 0/2][RFC] VFCIPI v3 Gregory Haskins
2007-07-31 15:40 ` Peter Zijlstra
2007-07-31 16:14 ` Gregory Haskins
2007-07-31 16:22 ` Peter Zijlstra
2007-07-31 16:26 ` Gregory Haskins
2007-07-31 16:14 ` Gregory Haskins
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=1185891957.12034.12.camel@twins \
--to=peterz@infradead.org \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
/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.