On 12/4/06, Wendy Cheng <[EMAIL PROTECTED]> wrote:
Russell Cattelan wrote:
> Wendy Cheng wrote:
>
>> Linux kernel, particularly the VFS layer, is starting to show signs
>> of inadequacy as the software components built upon it keep growing.
>> I have doubts that it can keep up and handle this com
Russell Cattelan wrote:
Wendy Cheng wrote:
Linux kernel, particularly the VFS layer, is starting to show signs
of inadequacy as the software components built upon it keep growing.
I have doubts that it can keep up and handle this complexity with a
development policy like you just described (f
Wendy Cheng wrote:
Andrew Morton wrote:
On Thu, 30 Nov 2006 11:05:32 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
The idea is, instead of unconditionally dropping every buffer
associated with the particular mount point (that defeats the purpose
of page caching), base kernel exports the
On Mon, 04 Dec 2006 00:57:50 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>Did you look at improving that lock-lookup algorithm, btw? Core kernel has
> >>>no problem maintaining millions of cached VFS objects - is there any reason
> >>>why your lock lookup cannot be similarly effici
Andrew Morton wrote:
On Sun, 03 Dec 2006 12:49:42 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
I read this as "It is ok to give system admin(s) commands (that this
"drop_pagecache_sb() call" is all about) to drop page cache. It is,
however, not ok to give filesystem developer(s) this very
On Sun, 03 Dec 2006 12:49:42 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> >On Thu, 30 Nov 2006 11:05:32 -0500
> >Wendy Cheng <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>
> >>The idea is, instead of unconditionally dropping every buffer associated
> >>with the particul
Andrew Morton wrote:
On Thu, 30 Nov 2006 11:05:32 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
The idea is, instead of unconditionally dropping every buffer associated
with the particular mount point (that defeats the purpose of page
caching), base kernel exports the "drop_pagecache_sb()
On Thu, 30 Nov 2006 11:05:32 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
> How about a simple and plain change with this uploaded patch
>
> The idea is, instead of unconditionally dropping every buffer associated
> with the particular mount point (that defeats the purpose of page
> cachin
On 11/30/06, Wendy Cheng <[EMAIL PROTECTED]> wrote:
How about a simple and plain change with this uploaded patch
The idea is, instead of unconditionally dropping every buffer associated
with the particular mount point (that defeats the purpose of page
caching), base kernel exports the "drop
How about a simple and plain change with this uploaded patch
The idea is, instead of unconditionally dropping every buffer associated
with the particular mount point (that defeats the purpose of page
caching), base kernel exports the "drop_pagecache_sb()" call that allows
page cache to be
Andrew Morton wrote:
We shouldn't export this particular implementation to modules because it
has bad failure modes. There might be a case for exposing an
i_sb_list-based API or, perhaps better, a max-unused-inodes mount option.
Ok, thanks for looking into this - it is appreciated. I'll tr
On Tue, 28 Nov 2006 16:41:07 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Mon, 27 Nov 2006 18:52:58 -0500
> > Wendy Cheng <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Not sure about walking thru sb->s_inodes for several reasons
> >>
> >> 1. First, the changes made a
Andrew Morton wrote:
On Mon, 27 Nov 2006 18:52:58 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
Not sure about walking thru sb->s_inodes for several reasons
1. First, the changes made are mostly for file server setup with large
fs size - the entry count in sb->s_inodes may not be shorte
On Mon, 27 Nov 2006 18:52:58 -0500
Wendy Cheng <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > This search is potentially inefficient. It would be better walk
> > sb->s_inodes.
> >
> >
> Not sure about walking thru sb->s_inodes for several reasons
>
> 1. First, the changes made are
Andrew Morton wrote:
This search is potentially inefficient. It would be better walk
sb->s_inodes.
Not sure about walking thru sb->s_inodes for several reasons
1. First, the changes made are mostly for file server setup with large
fs size - the entry count in sb->s_inodes may not be s
15 matches
Mail list logo