mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org, David Wilder <dwilder@us.ibm.com>,
	Tom Zanussi <zanussi@us.ibm.com>, Ingo Molnar <mingo@redhat.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Christoph Hellwig <hch@infradead.org>,
	ltt-dev@shafik.org, systemtap@sources.redhat.com,
	Douglas Niehaus <niehaus@eecs.ku.edu>,
	"Martin J. Bligh" <mbligh@mbligh.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] Relay CPU Hotplug support
Date: Wed, 20 Dec 2006 23:23:50 -0800	[thread overview]
Message-ID: <20061220232350.eb4b6a46.akpm@osdl.org> (raw)
In-Reply-To: <20061221003101.GA28643@Krystal>

On Wed, 20 Dec 2006 19:31:01 -0500
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> Hi,
> 
> Here is a patch, result of the combined work of Tom Zanussi and myself, to add
> CPU hotplug support to Relay.
> 
> ...
>
> +
> +	lock_cpu_hotplug();
> +	for_each_online_cpu(i)
> +		if (chan->buf[i])
> +			__relay_reset(chan->buf[i], 0);
> +	unlock_cpu_hotplug();

__relay_reset() runs flush_scheduled_work().  If one of the queued works
takes lock_cpu_hoplug() (and some do), thou art most deadest meat.

I think the core design problem you have here is that you are using
cpu_online_map to record the presence or absence of resources which belong
to the relay driver.  Why do that - you don't own cpu_online_map (but you
do get some notifications when it wants to change, that's all).

Perhaps a better approach would be to teach the relay driver to maintain
its own resources (already there, in chan->buf[]).  So relay.c has a record
of which per-cpu buffers are present and which are not.  That information
gets changed under a lock which the relay driver owns and controls.

You already have such a lock: relay_channels_mutex.  So some code in here
is using lock_cpu_hotplug() to protect relay's resources while other code
is using relay_channels_mutex.    Which is it?


Your proposed change apparently chooses to not release per-cpu resources on
cpu-hotunplug.  I think.  That's the sort of thing which should be
communicated in the (presently non-existent) patch changelog.

The changelog should also tell us *why* this patch was written.  Right now
it's in "why on earth should we merge this" territory.




Meanwhile, let's shrink 10% off of relay.o's .text, shall we?


--- a/kernel/relay.c~relay-remove-inlining
+++ a/kernel/relay.c
@@ -322,7 +322,7 @@ static void wakeup_readers(struct work_s
  *
  *	See relay_reset for description of effect.
  */
-static inline void __relay_reset(struct rchan_buf *buf, unsigned int init)
+static void __relay_reset(struct rchan_buf *buf, unsigned int init)
 {
 	size_t i;
 
@@ -418,7 +418,7 @@ static struct rchan_buf *relay_open_buf(
  *	The channel buffer and channel buffer data structure are then freed
  *	automatically when the last reference is given up.
  */
-static inline void relay_close_buf(struct rchan_buf *buf)
+static void relay_close_buf(struct rchan_buf *buf)
 {
 	buf->finalized = 1;
 	cancel_delayed_work(&buf->wake_readers);
@@ -426,7 +426,7 @@ static inline void relay_close_buf(struc
 	kref_put(&buf->kref, relay_remove_buf);
 }
 
-static inline void setup_callbacks(struct rchan *chan,
+static void setup_callbacks(struct rchan *chan,
 				   struct rchan_callbacks *cb)
 {
 	if (!cb) {
@@ -946,11 +946,10 @@ typedef int (*subbuf_actor_t) (size_t re
 /*
  *	relay_file_read_subbufs - read count bytes, bridging subbuf boundaries
  */
-static inline ssize_t relay_file_read_subbufs(struct file *filp,
-					      loff_t *ppos,
-					      subbuf_actor_t subbuf_actor,
-					      read_actor_t actor,
-					      read_descriptor_t *desc)
+static ssize_t relay_file_read_subbufs(struct file *filp, loff_t *ppos,
+					subbuf_actor_t subbuf_actor,
+					read_actor_t actor,
+					read_descriptor_t *desc)
 {
 	struct rchan_buf *buf = filp->private_data;
 	size_t read_start, avail;
_


  parent reply	other threads:[~2006-12-21  7:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-21  0:31 Mathieu Desnoyers
2006-12-21  1:13 ` Tom Zanussi
2006-12-21  3:22   ` Mathieu Desnoyers
2006-12-21  7:23 ` Andrew Morton [this message]
2006-12-21  7:04   ` Tom Zanussi
2006-12-22 10:37   ` Gautham R Shenoy
2006-12-22 10:44     ` Andrew Morton
2006-12-22 16:20       ` Oleg Nesterov
2006-12-22 16:42         ` Oleg Nesterov
2006-12-22 20:01       ` Gautham R Shenoy

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=20061220232350.eb4b6a46.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=dwilder@us.ibm.com \
    --cc=gregkh@suse.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mbligh@mbligh.org \
    --cc=mingo@redhat.com \
    --cc=niehaus@eecs.ku.edu \
    --cc=systemtap@sources.redhat.com \
    --cc=tglx@linutronix.de \
    --cc=zanussi@us.ibm.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

all inboxes | Powered by JetHome®