linux-kernel - [RFC] [PATCH 0/3] Writeback livelock avoidance using page tags (v2)

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-next>] [day] [month] [year] [list]

Message-Id: <1265929584-5080-1-git-send-email-jack@suse.cz>
Date:	Fri, 12 Feb 2010 00:06:21 +0100
From:	Jan Kara <jack@...e.cz>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, npiggin@...e.de,
	fengguang.wu@...el.com
Subject: [RFC] [PATCH 0/3] Writeback livelock avoidance using page tags (v2)

  Hi,

  the following two patches (the third one is just a debugging aid, not to be
merged) implement avoidance of livelock of write_cache_pages.  The idea is
simple: We tag patches that should be written in the beginning of
write_cache_pages and then write only tagged pages (see the patch for details).
Since last version, I've made tagging function faster as Andrew suggested and
also gave the patch more testing.
  The thing I've aimed at with this patch is a simplification of current
writeback code. Basically, with this patch I think we can just rip out all the
range_cyclic and nr_to_write (or other "fairness logic"). The rationalle is
following:
  What we want to achieve with fairness logic is that when a page is
dirtied, it gets written to disk within some reasonable time (like 30s or
so). We track dirty time on per-inode basis only because keeping it
per-page is simply too expensive. So in this setting fairness between
inodes really does not make any sence - why should be a page in a file
penalized and written later only because there are lots of other dirty
pages in the file? It is enough to make sure that we don't write one file
indefinitely when there are new dirty pages continuously created - and my
patch achieves that.
  Comments and suggestions for improvement are welcome!

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