On Fri, Jun 29, 2001 at 08:01:55AM -0700, Lever, Charles wrote:
>
> > Fs-independent and fs-private parts are allocated separately.
> > On systems
> > with "VNODE style interface" So I'm not sure what are you
> > talking about.
>
> actually, they're not.
>
> the fs-private implementations on
On Fri, 29 Jun 2001, Lever, Charles wrote:
> the fs-private implementations on these systems allocate the
> in-core vnode struct, and usually allocate the private area
> right off the end of the fs-independent part of the vnode.
> then they plant a pointer in the vnode to the fs-private area.
>
> Fs-independent and fs-private parts are allocated separately.
> On systems
> with "VNODE style interface" So I'm not sure what are you
> talking about.
actually, they're not.
the fs-private implementations on these systems allocate the
in-core vnode struct, and usually allocate the private
On Thursday 28 June 2001 03:48, Alexander Viro wrote:
> On Thu, 28 Jun 2001, Daniel Phillips wrote:
> > > Advantages: no extra memory use, no indirection, no memory allocation
> > > overhead.
> >
> > An advantage you overlooked: clean up fs.h so it doesn't have to include
> > every filesystem in t
On Thursday 28 June 2001 07:39, Alexander Viro wrote:
> BTW, cost of extra dereferncing is trivial - when we access ext2-specific
> part of inode we usually
> a) do it more than once in a given function
> b) access a lot of stuff outside of struct inode.
It's not the only cost:
- T
On Thu, 28 Jun 2001, Andrew Morton wrote:
> So the rule should be: if your private inode info is larger
> than ext2's, you should allocate it separately.
Wrong. There is /proc. There is devfs or its equivalents. There are
pipes and sockets.
"bloated inodes are OK since ext2 is all that matter
Linus Torvalds wrote:
>
> If we're going to do this for a major filesystem, then I'd really just
> rather see this being done generically during 2.5.x, making "u" be a
> pointer only, and having the generic "iput()" just always free the dang
> thing.
Here are the actual sizes, on x86 SMP, from 2
On Wed, 27 Jun 2001, Linus Torvalds wrote:
>
> On Wed, 27 Jun 2001, Alexander Viro wrote:
> >
> > We get inode initilization (generic parts) spread all over the place and
> > sooner or later it's going to bite us, for one thing.
>
> I don't really think so. The "struct inode" has become less
On Thu, 28 Jun 2001, Daniel Phillips wrote:
> >
> > Advantages: no extra memory use, no indirection, no memory allocation
> > overhead.
>
> An advantage you overlooked: clean up fs.h so it doesn't have to include
> every filesystem in the known universe.
>
> All of this also applies to struc
On Wednesday 27 June 2001 23:22, Linus Torvalds wrote:
> we could _easily_ have the setup
>
> struct ext2_inode {
> struct inode inode; /* Generic fields */
> specific-ext2 struct; /* specific fields */
> };
>
> and then when ext2 calls down to the gen
At 22:43 27/06/2001, Alexander Viro wrote:
>On Wed, 27 Jun 2001, Linus Torvalds wrote:
> > and then when ext2 calls down to the generic VFS layer it just passes
> >
> > &ext2_inode->inode
> >
> > down, and when it gets a "struct inode *" it uses "inode_to_ext2()" to
> > convert it to an ext2
On Wed, 27 Jun 2001, Alexander Viro wrote:
>
> We get inode initilization (generic parts) spread all over the place and
> sooner or later it's going to bite us, for one thing.
I don't really think so. The "struct inode" has become less and less
important as far as the VFS layer is concerned, and
On Wed, 27 Jun 2001, Linus Torvalds wrote:
> and then when ext2 calls down to the generic VFS layer it just passes
>
> &ext2_inode->inode
>
> down, and when it gets a "struct inode *" it uses "inode_to_ext2()" to
> convert it to an ext2 inode pointer.
>
> This is what the "struct list_
On Wed, 27 Jun 2001, Ben LaHaise wrote:
> Are you certain that adding yet another level of pointer indirection here
> is a good idea? The whole cache miss and indirection issue is exactly why
> almost all systems in the world make use of a VNODE style interface.
Ben, mind looking into /src/sy
On Wed, 27 Jun 2001, Ben LaHaise wrote:
> On Wed, 27 Jun 2001, Linus Torvalds wrote:
>
> > If we're going to do this for a major filesystem, then I'd really just
> > rather see this being done generically during 2.5.x, making "u" be a
> > pointer only, and having the generic "iput()" just always
If we're going to do this for a major filesystem, then I'd really just
rather see this being done generically during 2.5.x, making "u" be a
pointer only, and having the generic "iput()" just always free the dang
thing.
Linus
-
To unsubscribe from this list: send the line "unsubs
On Mon, 25 Jun 2001, Trond Myklebust wrote:
> > " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> > Fine. I've moved call of nfs_refresh_inode() into both
> > branches, expanded it in the "got the new inode, need to fill
> > it" one and removed the redundant stuff there.
>
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> On Mon, 25 Jun 2001, Trond Myklebust wrote:
>> As I said, the patch looks good, and the races are gone. The
>> only question I have is about the above section in
>> nfs_fhget(). AFAICS the NFS_CACHEINV() you've inserted
On Mon, 25 Jun 2001, Trond Myklebust wrote:
> As I said, the patch looks good, and the races are gone. The only
> question I have is about the above section in nfs_fhget(). AFAICS the
> NFS_CACHEINV() you've inserted here will get clobbered by the
> nfs_refresh_inode() below it.
Erm... Sorr
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> Trond, could you review the patch below? I believe that it's
> OK
> wrt races around iget(), but I'd appreciate if you take a look
> at it.
> + NFS_CACHEINV(inode);
> + /* Why so? Because we want revalidat
> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
> On Fri, 22 Jun 2001, Anton Altaparmakov wrote:
>> Just as a matter of interest: why do you define NFS_I as a
>> static inline function while you leave NFS_FS as a preprocessor
>> macro? I assume there is some good reason
On Fri, 22 Jun 2001, Anton Altaparmakov wrote:
> >-#define NFS_FH(inode) (&(inode)->u.nfs_i.fh)
[snip]
> >+#define NFS_FH(inode) (&NFS_I(inode)->fh)
>
> Al,
>
> Just as a matter of interest: why do you define NFS_I as a static inline
> function while you lea
At 09:03 22/06/2001, Alexander Viro wrote:
>At 08:00 22/06/2001, Alexander Viro wrote:
>[snip]
>>diff -urN S6-pre5/include/linux/nfs_fs.h S6-pre5-NFS/include/linux/nfs_fs.h
>>--- S6-pre5/include/linux/nfs_fs.h Sat Jun 16 15:53:57 2001
>>+++ S6-pre5-NFS/include/linux/nfs_fs.h Fri Jun 22 00:21
At 08:00 22/06/2001, Alexander Viro wrote:
[snip]
>diff -urN S6-pre5/include/linux/nfs_fs.h S6-pre5-NFS/include/linux/nfs_fs.h
>--- S6-pre5/include/linux/nfs_fs.h Sat Jun 16 15:53:57 2001
>+++ S6-pre5-NFS/include/linux/nfs_fs.h Fri Jun 22 00:21:50 2001
>@@ -63,39 +63,44 @@
> */
> #define
Trond, could you review the patch below? I believe that it's OK
wrt races around iget(), but I'd appreciate if you take a look at it.
Effect on sizeof(struct inode): 464 bytes -> 384 bytes. On K7 it
means 10 inodes per page instead of 7...
diff -urN S6-pre5/fs/nfs/flushd.c S6-pre
25 matches
Mail list logo
