From: Hans Reiser <reiser@namesys.com>
To: Jens Axboe <axboe@suse.de>
Cc: "Vladimir V. Saveliev" <vs@namesys.com>,
Tom Vier <tmv@comcast.net>,
Linux-Kernel@vger.kernel.org,
Reiserfs developers mail-list <Reiserfs-Dev@namesys.com>,
Reiserfs mail-list <Reiserfs-List@namesys.com>
Subject: Re: [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer)
Date: Wed, 14 Jun 2006 12:37:39 -0700 [thread overview]
Message-ID: <44906583.6070007@namesys.com> (raw)
In-Reply-To: <20060608113517.GC5207@suse.de>
Jens Axboe wrote:
>On Thu, Jun 08 2006, Vladimir V. Saveliev wrote:
>
>
>>Hello
>>
>>On Thu, 2006-06-08 at 13:00 +0200, Jens Axboe wrote:
>>
>>
>>>On Wed, May 24 2006, Hans Reiser wrote:
>>>
>>>
>>>>Tom Vier wrote:
>>>>
>>>>
>>>>
>>>>>On Tue, May 23, 2006 at 01:14:54PM -0700, Hans Reiser wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>underlying FS can be improved. Performance results show that the new
>>>>>>code consumes 40% less CPU when doing "dd bs=1MB ....." (your hardware,
>>>>>>and whether the data is in cache, may vary this result). Note that this
>>>>>>has only a small effect on elapsed time for most hardware.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Write requests in linux are restricted to one page?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>It may go to the kernel as a 64MB write, but VFS sends it to the FS as
>>>>64MB/4k separate 4k writes.
>>>>
>>>>
>>>Nonsense,
>>>
>>>
>>Hans refers to generic_file_write which does
>>prepare_write
>>copy_from_user
>>commit_write
>>for each page.
>>
>>
>
>Provide your own f_op->write() ?
>
>
In Unix VFS is an abstraction layer with a philosophical commitment to
allow filesystems to do their own thing, but Linux is quite different,
and what you suggest got vetoed with emphasis. In all fairness, the
patch vs is sending is one I can live with that allows me to not worry
about aio code and direct io code, neither of which interest me at this
time. So I suppose there is some benefit to all this hassle.
>
>
>>>there are ways to get > PAGE_CACHE_SIZE writes in one chunk.
>>>Other file systems have been doing it for years.
>>>
>>>
>>>
>>Would you, please, say more about it.
>>
>>
>
>Use writepages?
>
>
>
writepages is flush time code, this is sys_write() code. sys_write
first sticks things into the cache,, then memory pressure or pages
reaching maximum time allowed in memory or fsync pushes them out to
disk, at which time writepages might get used.
This issue is about cached writes losing performance when done 4k at a
time. It is very similar to why bios are better than submitting io 4k
at a time, but it is at a different stage.
Christoph Hellwig wrote:
>That's not really the vfs but the generic pagecache routines. For some
>filesystems (e.g. XFS) only reservations for delayed allocations are
>performed in this path so it doesn't really matter. For not so advanced
>filesystems batching these calls would definitly be very helpful. Patches
>to get there are very welcome.
>
>
>
Glad we all agree. vs is sending a pseudocoded proposal.
next prev parent reply other threads:[~2006-06-14 19:37 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-23 20:14 [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer) Hans Reiser
2006-05-23 20:26 ` Alexey Polyakov
2006-05-23 20:33 ` Michal Piotrowski
2006-05-24 14:39 ` Vladimir V. Saveliev
2006-06-08 10:45 ` Jan Engelhardt
2006-06-08 12:40 ` Vladimir V. Saveliev
2006-06-08 14:11 ` Jan Engelhardt
2006-05-24 17:53 ` Tom Vier
2006-05-24 17:55 ` Hans Reiser
2006-06-08 11:00 ` Jens Axboe
2006-06-08 11:26 ` Vladimir V. Saveliev
2006-06-08 11:35 ` Jens Axboe
2006-06-08 12:08 ` Vladimir V. Saveliev
2006-06-14 19:37 ` Hans Reiser [this message]
2006-06-08 12:10 ` Christoph Hellwig
2006-06-14 22:08 ` batched write Vladimir V. Saveliev
2006-06-17 17:04 ` Andrew Morton
2006-06-17 17:51 ` Hans Reiser
2006-06-18 11:20 ` Nix
2006-06-19 9:05 ` Hans Reiser
2006-06-19 11:32 ` Miklos Szeredi
2006-06-19 16:39 ` Hans Reiser
2006-06-19 17:35 ` Miklos Szeredi
2006-06-19 17:52 ` Akshat Aranya
2006-06-19 20:39 ` Hans Reiser
2006-06-19 16:27 ` Andreas Dilger
2006-06-19 16:51 ` Hans Reiser
2006-06-19 18:50 ` Andreas Dilger
2006-06-19 20:47 ` Hans Reiser
2006-06-20 0:01 ` David Chinner
2006-06-20 7:19 ` Hans Reiser
2006-06-20 7:26 ` Andrew Morton
2006-06-20 9:02 ` Steven Whitehouse
2006-06-20 16:26 ` Vladimir V. Saveliev
2006-06-20 17:29 ` Hans Reiser
2006-06-19 18:28 ` Vladimir V. Saveliev
2006-05-24 17:59 ` [PATCH] updated reiser4 - reduced cpu usage for writes by writing more than 4k at a time (has implications for generic write code and eventually for the IO layer) Hans Reiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44906583.6070007@namesys.com \
--to=reiser@namesys.com \
--cc=Linux-Kernel@vger.kernel.org \
--cc=Reiserfs-Dev@namesys.com \
--cc=Reiserfs-List@namesys.com \
--cc=axboe@suse.de \
--cc=tmv@comcast.net \
--cc=vs@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox