mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.29 -mm merge plans
Date: Thu, 15 Jan 2009 17:37:03 +1100	[thread overview]
Message-ID: <200901151737.03600.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20090112140606.cd6f208c.akpm@linux-foundation.org>

On Tuesday 13 January 2009 09:06:06 Andrew Morton wrote:
> On Mon, 5 Jan 2009 23:28:26 +1100
>
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > On Monday 05 January 2009 19:43:00 Andrew Morton wrote:
> > > The individual patches are mostly at
> > > http://userweb.kernel.org/~akpm/mmotm/broken-out/
> > >
> > >
> > > mm-remove-the-might_sleep-from-lock_page.patch
> > >
> > >   Need to think about this.
> >
> > Removing this reduces a lot of might_sleep coverage scope. Page
> > lock isn't contended in a lot of cases. Why would you drop a
> > good debugging feature?
>
> For the reasons described in the changelog, of course.
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-remove-the-might_sleep-
>from-lock_page.patch

Yeah, but that's because voluntary preempt is somewhat of a hack.
In fact, we recently decided to turn this off in SLES11 because it
was causing a measurable performance slowdown.

If you are actually debugging a page lock problem or writing new
code, you would be very very happy to have a problem caught here
rather than the potentially much harder task of causing a
schedule on this lock.


> > > make-sure-nobodys-leaking-resources.patch
> > > releasing-resources-with-children.patch
> >
> > Any reason why not to add these upstream?
>
> Dunno.  Are they valuable?  I've never had a report of them triggering,
> I don't think.

I don't really know the code, but if it gives extra help to
people writing or testing new devices... is it difficult to
carry around? If not, then why *not* have it upstream? ;)


> > > put_bh-debug.patch
> >
> > This could just be implemented with a VM_BUG_ON (or FS_BUG_ON) like the
> > pagecache refcounting. Wouldn't be a bad idea.
>
> yup, I guess so.  Again, no reports of it triggering in ages.

Maybe I'll go through and add some such assertions for fs developers.
fsblock is riddled with them and it really really helps catching weird
and wonderful problems in the buffer layer, the pagecache layer, or
the filesystem, or some combination of them ;) Maybe that's just
because I write a lot of bugs though!


> > > add-a-refcount-check-in-dput.patch
> >
> > Again, why not an FS_BUG_ON for things like this too?
>
> Ditto.

OK.


  reply	other threads:[~2009-01-15  6:37 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05  8:43 Andrew Morton
2009-01-05  9:00 ` KOSAKI Motohiro
2009-01-05  9:07   ` Andrew Morton
2009-01-05 22:31     ` Ying Han
2009-01-05 22:34     ` Valdis.Kletnieks
2009-01-08  4:18       ` Ying Han
2009-01-08  4:41         ` KOSAKI Motohiro
2009-01-08  7:57           ` Ying Han
2009-01-08  8:31             ` KOSAKI Motohiro
2009-01-11  4:18         ` Valdis.Kletnieks
2009-01-12  4:18           ` Ying Han
2009-01-06  5:27   ` Valdis.Kletnieks
2009-01-06  5:41     ` Nick Piggin
2009-01-05  9:02 ` Sam Ravnborg
2009-01-05  9:12   ` Andrew Morton
2009-01-05  9:17     ` David Miller
2009-01-05  9:21       ` Ingo Molnar
2009-01-05  9:39         ` Sam Ravnborg
2009-01-05 10:10           ` Ingo Molnar
2009-01-05 10:36             ` David Miller
2009-01-05 12:32               ` Ingo Molnar
2009-01-05 10:11     ` Ingo Molnar
2009-01-05 10:37       ` David Miller
2009-01-05  9:40 ` Ryusuke Konishi
2009-01-06 13:30   ` Pekka Enberg
2009-01-07  3:26     ` Ryusuke Konishi
2009-01-07  7:58       ` Pekka Enberg
2009-01-07 14:17       ` Chris Mason
2009-01-05 11:34 ` Al Viro
2009-01-05 11:40 ` Stephen Rothwell
2008-10-06  6:14   ` Greg Ungerer
2009-01-05 12:17   ` Ingo Molnar
2009-01-05 17:38   ` KOSAKI Motohiro
2009-01-05 12:28 ` Nick Piggin
2009-01-12 22:06   ` Andrew Morton
2009-01-15  6:37     ` Nick Piggin [this message]
2009-01-06  9:46 ` Pavel Machek
2009-01-06 22:33 ` Folkert van Heusden
2009-01-06 22:38   ` Alan Cox
2009-01-06 22:57 ` Christoph Hellwig
2009-01-06 23:08   ` Andrew Morton
2009-01-07  1:05     ` Nick Piggin
2009-01-06 23:08   ` Andrew Morton
2009-01-06 23:22     ` Christoph Hellwig
2009-01-07  2:16       ` Dave Chinner
2009-01-08 15:50         ` Dmitri Monakhov
2009-01-06 23:11   ` Andrew Morton
2009-01-06 23:24     ` Christoph Hellwig
2009-01-07  1:14       ` Nick Piggin
2009-01-07  1:38         ` Andi Kleen
2009-01-07  1:49           ` Nick Piggin
2009-01-07  2:57             ` Andi Kleen
2009-01-07  3:28               ` Nick Piggin
2009-01-08 13:24               ` Pavel Machek
2009-01-10 15:07                 ` Andi Kleen
2009-01-10 21:32                   ` sync, reboot, and corrupting data [was Re: 2.6.29 -mm merge plans] Pavel Machek
2009-01-10 22:12                     ` Andi Kleen
2009-01-10 22:26                       ` Pavel Machek
2009-01-08 13:22       ` 2.6.29 -mm merge plans Pavel Machek
2009-01-06 23:13   ` Andrew Morton
2009-01-06 23:24     ` Christoph Hellwig
2009-01-06 23:38       ` Andrew Morton
2009-01-07  2:06     ` Nick Piggin
2009-01-07  2:16       ` Andrew Morton
2009-01-07  3:05         ` Nick Piggin
2009-01-07  4:16           ` Andrew Morton
2009-01-06 23:15   ` Andrew Morton
2009-01-06 23:25     ` Christoph Hellwig
2009-01-07  7:54       ` Christoph Hellwig
2009-01-07  7:59         ` Andrew Morton
2009-01-07  8:10           ` Christoph Hellwig
2009-01-06 23:17   ` Andrew Morton
2009-01-06 23:19     ` Christoph Hellwig
2009-01-06 23:26       ` Warren Turkal
2009-01-06 23:26         ` Warren Turkal
2009-01-12  3:19         ` Roman Zippel
2009-01-06 23:27       ` Diego E. 'Flameeyes' Pettenò
2009-01-06 23:31         ` Christoph Hellwig
2009-01-06 23:49           ` Harvey Harrison
2009-01-07  0:09           ` Diego E. 'Flameeyes' Pettenò
2009-01-07  0:16             ` Harvey Harrison
2009-01-12  4:21         ` Roman Zippel
2009-01-06 23:19   ` Andrew Morton
2009-01-08 19:11     ` Rodolfo Giometti
2009-01-12 20:23       ` Christoph Hellwig
2009-01-13  9:49         ` Rodolfo Giometti
2009-01-12 20:22     ` Christoph Hellwig
2009-01-13  9:47       ` Rodolfo Giometti
2009-01-06 23:21   ` Andrew Morton
2009-01-06 23:28   ` Andrew Morton
2009-01-07  2:21     ` Nick Piggin
2009-01-08  8:39       ` Miklos Szeredi
2009-01-15  6:45         ` Nick Piggin
2009-01-07  0:01 ` Dan Williams

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=200901151737.03600.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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®