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
| ||
|
Date: Mon, 16 Jun 2008 21:54:06 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Rik van Riel <riel@...hat.com> Cc: Hugh Dickins <hugh@...itas.com>, Jens Axboe <jens.axboe@...cle.com>, Lee Schermerhorn <lee.schermerhorn@...com>, Pavel Machek <pavel@...e.cz>, mtk.manpages@...il.com, kernel list <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...k.pl> Subject: Re: sync_file_range(SYNC_FILE_RANGE_WRITE) blocks? On Mon, 16 Jun 2008 16:53:51 -0400 Rik van Riel <riel@...hat.com> wrote: > On Mon, 2 Jun 2008 13:40:28 +0100 (BST) > Hugh Dickins <hugh@...itas.com> wrote: > > On Mon, 2 Jun 2008, Jens Axboe wrote: > > > On Sun, Jun 01 2008, Andrew Morton wrote: > > > > > > > > Well if you're asking the syscall to shove more data into the block > > > > layer than it can concurrently handle, sure, the block layer will > > > > block. It's tunable... > > > > > > Ehm, lets get the history right, please :-) > > > > > > The block layer pretty much doesn't care about how large the queue > > > size is, it's largely at 128 to prevent the vm from shitting itself > > > like it has done in the past (and continues to do I guess, though > > > your reply leaves me wondering). > > > > > > So you think the vm will be fine with a huge number of requests? > > > It wont go nuts scanning and reclaiming, wasting oodles of CPU > > > cycles? > > > > Interesting. I wonder. I may be quite wrong (Cc'ed Rik and Lee > > who I think are currently most in touch with what goes on there), > > but my impression is that whereas vmscan.c takes pages off LRU > > while it's doing writeback on them, and arranges for them to go > > back to the reclaimable tail of the LRU > > The problem with lots of CFQ requests is simpler. > > If you look at balance_dirty_pages() you will see that it only > takes dirty and NFS unstable pages into account when checking > the dirty limit. The pages that are in flight (under IO) are > not counted at all. That would be totally busted. All that nr_writeback logic in there is very much supposed to handle under-writeback pages? > If you have 8192 CFQ requests and large streaming IO, most of > the IOs will be mergeable and it is possible to pin all of > memory in in-flight (PG_writeback - and other?) pages. > > I suspect that balance_dirty_pages() will have to take the > writeback pages into account, though that may cause problems > with FUSE. Maybe it should at least wait for some IO to > complete? Worried. One of us is missing something here. -- 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/
Powered by blists - more mailing lists