linux-kernel - Re: [PATCH 2/3] mm: Implement writeback livelock avoidance using page tagging

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: <20100215162127.GU5723@laptop>
Date:	Tue, 16 Feb 2010 03:21:27 +1100
From:	Nick Piggin <npiggin@...e.de>
To:	Jan Kara <jack@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, fengguang.wu@...el.com
Subject: Re: [PATCH 2/3] mm: Implement writeback livelock avoidance using
 page tagging

On Mon, Feb 15, 2010 at 04:47:51PM +0100, Jan Kara wrote:
> On Fri 12-02-10 11:39:55, Andrew Morton wrote:
> > On Fri, 12 Feb 2010 00:06:23 +0100
> > Jan Kara <jack@...e.cz> wrote:
> > 
> > > The idea is simple: Tag all pages that should be written back
> > > with a special tag (TOWRITE) in the radix tree. This can be done
> > > rather quickly and thus livelocks should not happen in practice.
> > > Then we start doing the hard work of locking pages and sending
> > > them to disk only for those pages that have TOWRITE tag set.
> > 
> > Adding a second pass across all the pages sounds expensive?
>   Strictly speaking it's just through the radix tree and only through
> branches with DIRTY_TAG set. But yes, there is some additional CPU cost.
> I just thought that given the total cost of submitting a page it is
> an acceptable increase and the simplification is worth it.
>   Would some numbers make you happier? Any suggestion for measurements?
> Because I think that even for writes to tmpfs the change will be lost
> in the noise...

Although hmm, if it is a very large file with *lots* of dirty pages
then it might become a noticable proportion of the cost.

Dave Chinner would probably tell you he's seen files with many
gigabytes dirty, and what is nr_to_write set to? 1024 is it? So you
might be tagging hundreds or thousands of radix tree entries per
page you write.

Also, I wonder what you think about leaving the tags dangling when
the loop bails out early? I have a *slight* concern about this
because previously we never have a tag set when radix_tree_delete
is called. I actually had a bug in that code in earlier versions
of rcu radix tree that only got found by the user test harness.
And another slight concern that it is just a bit ugly to leave the
tag. But I can accept that lower CPU overhead trumps ugliness :)

--
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/