Bryan Henderson wrote:
You want to *use* the kernel pagecache as much as you can.
No, I really don't. Not always. I can think of only 2 reasons to
maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
allows me to share resources (memory and disk bandwidth come to mind)
u are talking about application aware caching/prefetching stuff. but i
prefer to modifying kernel page cache a little bit while make use of
most of the code there.
That's a powerful argument for using the page cache, and further, for
using it from within the kernel. I once started a project to
except that in iscsi a big chunk of the access patterns are *external*;
eg the real smarts are on that other machine on the network, not in the
iscsi server.
We strayed a little from the topic; I don't claim that a private
user-space cache is better than the page cache for an ISCSI server. My
On Wed, 2005-03-02 at 13:20, Bryan Henderson wrote:
u are talking about application aware caching/prefetching stuff. but i
prefer to modifying kernel page cache a little bit while make use of
most of the code there.
That's a powerful argument for using the page cache, and further, for
On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 10:46:03 +0100
fsync or msync() ? I would imagine the target mmaping it's backend
On Tue, 2005-03-01 at 11:33 +0100, Arjan van de Ven wrote:
On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 10:46:03 +0100
fsync
One thing that's implicit in your reasons for wanting to be in the kernel
is that you've chosen to exploit the kernel's page cache. As a user of
the page cache, you have more control from inside the kernel than from
user space. The page cache was designed to be fundamentally invisible to
Ming Zhang wrote:
On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
One thing that's implicit in your reasons for wanting to be in the kernel
is that you've chosen to exploit the kernel's page cache. As a user of
the page cache, you
On Tue, 2005-03-01 at 14:01, Vikas Aggarwal wrote:
And If future IET be visioned as an Enterprise Class Array(Multiple
Host-Side Adapters ie., FAs + Multiple Device Side Adapters ie., DAs),
should better be in direct control of all the system-resources without
being pushed out the kernel.
Arjan van de Ven [EMAIL PROTECTED] writes:
You want to *use* the kernel pagecache as much as you can. You do so by
using mmap and such, and msync to force content to disk. That uses the
Last time I checked you couldn't mmap block devices. Has this changed
now? Could be a problem for an iSCSI
it is hard to beat linux kernel [page] cache performance though.
It's quite easy to beat it for particular applications. You can use
special knowledge about the workload to drop pages that won't be accessed
soon in favor of pages that will, not clean a page that's just going to
get discarded
On Tue, 2005-03-01 at 16:04, Bryan Henderson wrote:
it is hard to beat linux kernel [page] cache performance though.
It's quite easy to beat it for particular applications. You can use
special knowledge about the workload to drop pages that won't be accessed
soon in favor of pages that
On Tue, Mar 01, 2005 at 09:38:34PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
You want to *use* the kernel pagecache as much as you can. You do so by
using mmap and such, and msync to force content to disk. That uses the
Last time I checked you couldn't mmap
Hi,
I would like to announce the iSCSI enterprise target (IET) software,
which is open-source software to build iSCSI storage systems. It can
provide disk volumes to iSCSI initiators by using any kinds of files
(regular files, block devices, virtual block devices like RAID and
LVM, etc). The
14 matches
Mail list logo
