All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Nick Bowler <nbowler@elliptictech.com>
Cc: linux-kernel@vger.kernel.org,
	Evgeniy Dushistov <dushistov@mail.ru>,
	Nick Piggin <npiggin@gmail.com>
Subject: Re: [PATCH 4/7] ufs: remove the BKL
Date: Wed, 2 Mar 2011 16:08:31 +0100	[thread overview]
Message-ID: <201103021608.31875.arnd@arndb.de> (raw)
In-Reply-To: <20110302144705.GA15482@elliptictech.com>

On Wednesday 02 March 2011, Nick Bowler wrote:
> On 2011-03-02 00:13 +0100, Arnd Bergmann wrote:
> > This introduces a new per-superblock mutex in UFS to replace
> > the big kernel lock. I have been careful to avoid nested
> > calls to lock_ufs and to get the lock order right with
> > respect to other mutexes, in particular lock_super.
> > 
> > I did not make any attempt to prove that the big kernel
> > lock is not needed in a particular place in the code,
> > which is very possible.
> > 
> > The code is still only compile-tested,
> 
> This isn't true anymore; I've been running with this patch (well, the
> previous versions thereof) for some time now.  On the other hand, I
> don't use all of this driver's features.

I'll updated the comment. Can I add your Tested-by tag?

> > but it should at least be harmless on non-SMP systems, since the new
> > mutex is not taken on those.
> 
> I think this part of the patch is strange.  It seems like a gratuitous
> difference between SMP/preempt and other systems to #if out the code
> that takes the mutex.  This might make problems with the conversion fly
> under the radar longer because people with older systems won't encounter
> them.

I agree it is strange, but the mutex has some serious performance impact
that I wanted to minimize on the systems where we know it is not needed.
The BKL was only active on those systems, so we know that non-SMP
non-preempt kernels don't need the mutex.

	Arnd

  reply	other threads:[~2011-03-02 15:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01 23:13 [PATCH 0/7] Final BKL removal, take 2 Arnd Bergmann
2011-03-01 23:13 ` [PATCH 1/7] staging/usbip: convert to kthread Arnd Bergmann
2011-03-01 23:13 ` [PATCH 2/7] staging/cx25721: serialize access to devlist Arnd Bergmann
2011-03-02 13:23   ` Palash Bandyopadhyay
2011-03-01 23:13 ` [PATCH 3/7] hpfs: remove the BKL Arnd Bergmann
2011-03-01 23:20   ` Andi Kleen
2011-03-01 23:13 ` [PATCH 4/7] ufs: " Arnd Bergmann
2011-03-02 14:47   ` Nick Bowler
2011-03-02 15:08     ` Arnd Bergmann [this message]
2011-03-02 15:48       ` Nick Bowler
2011-03-01 23:13 ` [PATCH 5/7] x25: " Arnd Bergmann
2011-03-01 23:16   ` David Miller
2011-03-03  7:38     ` Andrew Hendry
2011-03-01 23:13 ` [PATCH 6/7] appletalk: " Arnd Bergmann
2011-03-01 23:15   ` David Miller
2011-03-01 23:13 ` [PATCH 7/7] ipx: " Arnd Bergmann
2011-03-01 23:15   ` David Miller
2011-03-02  4:59 ` [PATCH 0/7] Final BKL removal, take 2 Greg KH
2011-03-02 11:32   ` Mauro Carvalho Chehab
2011-03-02 11:42     ` Arnd Bergmann
2011-03-02 14:04     ` Greg KH
2011-03-02 20:32       ` Mauro Carvalho Chehab
2011-03-02 21:54         ` Arnd Bergmann
2011-03-02 22:00           ` [PATCH v2] BKL: That's all, folks Arnd Bergmann

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=201103021608.31875.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=dushistov@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbowler@elliptictech.com \
    --cc=npiggin@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.