linux-kernel - Re: [PATCH 2/8] writeback: move dirty inodes from super_block to backing_dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090904071925.GQ18599@kernel.dk>
Date:	Fri, 4 Sep 2009 09:19:25 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	chris.mason@...cle.com, david@...morbit.com, tytso@....edu,
	akpm@...ux-foundation.org, jack@...e.cz
Subject: Re: [PATCH 2/8] writeback: move dirty inodes from super_block to
	backing_dev_info

On Thu, Sep 03, 2009 at 10:46:29PM -0400, Christoph Hellwig wrote:
> On Wed, Sep 02, 2009 at 10:42:41AM +0200, Jens Axboe wrote:
> > This is a first step at introducing per-bdi flusher threads. We should
> > have no change in behaviour, although sb_has_dirty_inodes() is now
> > ridiculously expensive, as there's no easy way to answer that question.
> > Not a huge problem, since it'll be deleted in subsequent patches.
> 
> After this patch generic_sync_sb_inodes becomes pretty useless.  We
> have two callers which each want to call bdi_writeback_all, and one of
> them wants to wait, so just split that into a separate helper.

Looks good.

> Also move wakeup_flusher_threads into fs-writeback.c, that allows us
> to make bdi_writeback_all static.

Ditto, I'll fold these in.

> Btw, I do not think implementing sync_inodes_sb/sync_inodes_sb_wait
> is a smart and efficient idea.  Right now we have a n:1 superblock:bdi
> relation, so we really should make use of that instead of doing linear
> search of all bdis in the system.  If we introduce multiple bdis per
> superblock we should add an efficient lookup data structure for them.

Yes definitely, the scan will get optimized. Once this is merged, I'll
attack the multiple bdis per superblock issue, since we'll need that
sooner rather than later. Pushing 2-3GB/s and up with buffered writeback
will require more than one thread.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/