All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <ntl@pobox.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Tejun Heo <htejun@gmail.com>,
	zwane@linuxpower.ca, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH linux-2.6 04/04] brsem: convert cpucontrol to brsem
Date: Sun, 25 Sep 2005 18:46:03 -0500	[thread overview]
Message-ID: <20050925234603.GA3577@otto> (raw)
In-Reply-To: <4336542D.4000102@yahoo.com.au>

Nick Piggin wrote:
> Tejun Heo wrote:
> 
> >+/*
> >+ * cpucontrol is a brsem used to synchronize cpu hotplug events.
> >+ * Invoking lock_cpu_hotplug() read-locks cpucontrol and no
> >+ * hotplugging events will occur until it's released.
> >+ *
> >+ * Unfortunately, brsem itself makes use of lock_cpu_hotplug() and
> >+ * performing brsem write-lock operations on cpucontrol deadlocks.
> >+ * This is avoided by...
> >+ *
> >+ * a. guaranteeing that cpu hotplug events won't occur during the
> >+ *    write-lock operations, and
> >+ *
> >+ * b. skipping lock_cpu_hotplug() inside brsem.
> >+ *
> >+ * #a is achieved by acquiring and releasing cpucontrol_mutex outside
> >+ * cpucontrol write-lock.  #b is achieved by skipping
> >+ * lock_cpu_hotplug() inside brsem if the current task is
> >+ * cpucontrol_mutex holder (is_cpu_hotplug_holder() test).
> >+ *
> >+ * Also, note that cpucontrol is first initialized with
> >+ * BRSEM_BYPASS_INITIALIZER and then initialized again with
> >+ * __create_brsem() instead of simply using create_brsem().  This is
> >+ * necessary as cpucontrol brsem gets used way before brsem subsystem
> >+ * becomes up and running.
> >+ *
> >+ * Until brsem is properly initialized, all brsem ops succeed
> >+ * unconditionally.  cpucontrol becomes operational only after
> >+ * cpucontrol_init() is finished, which should be called after
> >+ * brsem_init_early().
> >+ */
> 
> Mmm, this is just insane IMO.
> 
> Note that I happen to also think the idea (brsems) have merit, and
> that cpucontrol may be one of the places where a sane implementation
> would actually be useful... but at least when you're introducing
> this kind of complexity anywhere, you *really* need to be able to
> back it up with numbers.

The only performance-related complaint with cpu hotplug of which I'm
aware -- that taking a cpu down on a large system can be painfully
slow -- resides in the "write side" of the code, which is not the case
that the brsem implementation optimizes.  I think this patch would
make that case even worse.  So I don't think it's appropriate to use a
brsem for cpu hotplug, especially without trying rwsem first.


Nathan

  parent reply	other threads:[~2005-09-25 23:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-25  6:43 [PATCH linux-2.6 00/04] brsem: [RFC] big reader semaphore Tejun Heo
2005-09-25  6:43 ` [PATCH linux-2.6 01/04] brsem: implement " Tejun Heo
2005-09-25  7:19   ` Nick Piggin
2005-09-25  8:03     ` Nick Piggin
2005-09-25  8:11     ` Tejun Heo
2005-09-25  8:27       ` Nick Piggin
2005-09-25  8:53         ` Tejun Heo
2005-09-25  9:24           ` Nick Piggin
2005-09-25 10:05             ` Tejun Heo
2005-09-25 11:22               ` Nick Piggin
2005-09-25  6:43 ` [PATCH linux-2.6 02/04] brsem: convert super_block->s_umount to brsem Tejun Heo
2005-09-25  6:43 ` [PATCH linux-2.6 03/04] brsem: fix ro-remount <-> open race condition Tejun Heo
2005-09-25  6:43 ` [PATCH linux-2.6 04/04] brsem: convert cpucontrol to brsem Tejun Heo
2005-09-25  7:39   ` Nick Piggin
2005-09-25  8:03     ` Tejun Heo
2005-09-25 23:46     ` Nathan Lynch [this message]
2005-09-26  1:11       ` Nick Piggin
2005-09-26  4:05         ` Tejun Heo

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=20050925234603.GA3577@otto \
    --to=ntl@pobox.com \
    --cc=htejun@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zwane@linuxpower.ca \
    /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.