linux-kernel - Re: sync_file_range(SYNC_FILE_RANGE

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]

Date:	Mon, 16 Jun 2008 16:53:51 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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, 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.

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?

-- 
All rights reversed.
--
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/