[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080602114319.GI5757@kernel.dk>
Date: Mon, 2 Jun 2008 13:43:20 +0200
From: Jens Axboe <jens.axboe@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Pavel Machek <pavel@...e.cz>, mtk.manpages@...il.com,
Hugh Dickins <hugh@...itas.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 Sun, Jun 01 2008, Andrew Morton wrote:
> > > I expect major users of this system call will be applications which do
> > > small-sized overwrites into large files, mainly databases. That is,
> > > once the application developers discover its existence. I'm still
> > > getting expressions of wonder from people who I tell about the
> > > five-year-old fadvise().
> >
> > Hey, you have one user now, its called s2disk. But for this call to be
> > useful, we'd need asynchronous variant... is there such thing?
>
> 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?
--
Jens Axboe
--
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