linux-kernel - Re: Page Cache writeback too slow, SSD/noop scheduler/ext2

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: <C5F6B627.D9D0%jos@hyves.nl>
Date:	Mon, 30 Mar 2009 17:47:19 +0100
From:	Jos Houtman <jos@...es.nl>
To:	Wu Fengguang <fengguang.wu@...el.com>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	<linux-kernel@...r.kernel.org>, Jeff Layton <jlayton@...hat.com>,
	Dave Chinner <david@...morbit.com>,
	<linux-fsdevel@...r.kernel.org>, <jens.axboe@...cle.com>,
	<akpm@...ux-foundation.org>, <hch@...radead.org>,
	<linux-nfs@...r.kernel.org>
Subject: Re: Page Cache writeback too slow,   SSD/noop scheduler/ext2


>> Thanx for the patch, but for the next time: How should I apply it?
>> it seems to be context aware (@@) and broke on all kernel versions I tried
>> 2.6.28/2.6.28.7/2.6.29
> 
> Do you mean that the patch applies after removing " @@.*$"?

I didn't try that, but this time it worked. So it was probably my error.

> 
> You are right. In your case, there are several big dirty files in sdb1,
> and the sdb write queue is constantly (almost-)congested. The SSD write
> speed is so slow, that in each round of sdb1 writeback, it begins with
> an uncongested queue, but quickly fills up after writing some pages.
> Hence all the inodes will get redirtied because of (nr_to_write > 0).
> 
> The following quick fix should solve the slow-writeback-on-congested-SSD
> problem. However the writeback sequence is suboptimal: it sync-and-requeue
> each file until congested (in your case about 3~600 pages) instead of
> until MAX_WRITEBACK_PAGES=1024 pages.

Yeah that fixed it, but performance dropped due to the more constant
congestion. So I will need to try some different io schedulers.


Next to that I was wondering if there are any plans to make sure that not
all dirty-files are written back in the same interval.

In my case all database files are written back each 30 seconds, while I
would prefer them to be more divided over the interval.

Thanks,

Jos

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