All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Chandra Seetharaman <sekharan@us.ibm.com>,
	Alasdair G Kergon <agk@redhat.com>,
	dm-devel <dm-devel@redhat.com>,
	linux-kernel@vger.kernel.org, axboe@kernel.dk
Subject: Re: Queue upcall locking (was: [dm-devel] [RFC][PATCH] fix dm_any_congested() to properly sync up with suspend code path)
Date: Mon, 10 Nov 2008 15:26:50 +0100	[thread overview]
Message-ID: <1226327210.7685.173.camel@twins> (raw)
In-Reply-To: <Pine.LNX.4.64.0811100914500.14825@hs20-bc2-1.build.redhat.com>

On Mon, 2008-11-10 at 09:19 -0500, Mikulas Patocka wrote:
> On Mon, 10 Nov 2008, Christoph Hellwig wrote:
> 
> > On Mon, Nov 10, 2008 at 08:11:51AM -0500, Mikulas Patocka wrote:
> > > For upstream Linux developers: you are holding a spinlock and calling 
> > > bdi*_congested functions that can take indefinite amount of time (there 
> > > are even users reporting having 50 disks in one logical volume or so). I 
> > > think it would be good to move these calls out of spinlocks.
> > 
> > Umm, they shouldn't block that long, as that completely defeats their
> > purpose.  These functions are mostly used to avoid throwing more I/O at
> > a congested device if pdflush could do more useful things instead.  But
> > if it blocks in those functions anyway we wouldn't have to bother using
> > them.  Do you have more details about the uses cases when this happens
> > and where the routines spend so much time?
> 
> For device mapper, congested_fn asks every device in the tree and make OR 
> of their bits --- so if the user has 50 devices, it asks them all.
> 
> For md-linear, md-raid0, md-raid1, md-raid10 and md-multipath it does the 
> same --- asking every device.
> 
> If you have a better idea how to implement congested_fn, say it.

Fix the infrastructure by adding a function call so that you can have
the individual devices report their congestion state to the aggregate.

Then congestion_fn can return a valid state in O(1) because the state is
keps up-to-date by the individual state changes.

IOW, add a set_congested_fn() and clear_congested_fn().

  reply	other threads:[~2008-11-10 14:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06  4:00 [RFC][PATCH] fix dm_any_congested() to properly sync up with suspend code path Chandra Seetharaman
2008-11-10 13:11 ` Queue upcall locking (was: [RFC][PATCH] fix dm_any_congested() to properly sync up with suspend code path) Mikulas Patocka
2008-11-10 13:11   ` Queue upcall locking (was: [dm-devel] " Mikulas Patocka
2008-11-10 13:54   ` Queue upcall locking (was: " Christoph Hellwig
2008-11-10 13:54     ` Queue upcall locking (was: [dm-devel] " Christoph Hellwig
2008-11-10 14:19     ` Queue upcall locking (was: " Mikulas Patocka
2008-11-10 14:19       ` Queue upcall locking (was: [dm-devel] " Mikulas Patocka
2008-11-10 14:26       ` Peter Zijlstra [this message]
2008-11-10 14:32         ` Queue upcall locking (was: " Mikulas Patocka
2008-11-10 14:32           ` Queue upcall locking (was: [dm-devel] " Mikulas Patocka
2008-11-10 14:46           ` Peter Zijlstra
2008-11-10 14:55             ` Queue upcall locking (was: " Mikulas Patocka
2008-11-10 14:55               ` Queue upcall locking (was: [dm-devel] " Mikulas Patocka
2008-11-10 14:35         ` Queue upcall locking (was: " Alasdair G Kergon
2008-11-10 14:35           ` Queue upcall locking (was: [dm-devel] " Alasdair G Kergon
2008-11-11 18:18       ` Queue upcall locking (was: " Christoph Hellwig
2008-11-11 18:18         ` Queue upcall locking (was: [dm-devel] " Christoph Hellwig
2008-11-11 22:08         ` Queue upcall locking (was: " Mikulas Patocka
2008-11-11 22:08           ` Queue upcall locking (was: [dm-devel] " Mikulas Patocka
2008-11-10 14:27     ` Queue upcall locking (was: " Alasdair G Kergon
2008-11-10 14:27       ` Queue upcall locking (was: [dm-devel] " Alasdair G Kergon
2008-11-10 14:40       ` Queue upcall locking (was: " Mikulas Patocka
2008-11-10 14:40         ` Queue upcall locking (was: [dm-devel] " Mikulas Patocka
2008-11-11 18:22         ` Christoph Hellwig
2008-11-11 18:21       ` Christoph Hellwig

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=1226327210.7685.173.camel@twins \
    --to=peterz@infradead.org \
    --cc=agk@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=sekharan@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 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.