Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 23 Apr 2001 21:37:10 -0400 | Subject | Re: hundreds of mount --bind mountpoints? | From | Jan Harkes <> |
| |
On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote: > Last time we suggested this, people ended up with some OS trying > it and getting worse performance. > > Why? You need to allocate the VFS-inode (vnode in other OSs) and > the on-disk-inode anyway at the same time. You get better > performance and less fragmentation, if you allocate them both > together[1]. > > So that struct inode around is ok. > > BTW: Is it still less than one page? Then it doesn't make me > nervous. Why? Guess what granularity we allocate at, if we > just store pointers instead of the inode.u. Or do you like > every FS creating his own slab cache?
I've actually got the coda_inode_info (inode->u.u_coda_fs_i) split out of the union in my development kernel. It doesn't shrink the size of the struct inode yet, Coda isn't the biggest user at the moment.
But, it forced me to do several cleanups in the code, and it even has resulted in fixing a 'leak'. Not a real memory loss leak one, but we left uninitialized inodes around in the icache for no good reason. Also changing a but in a coda specific header file does trigger an almost complete rebuild of the whole kernel (coda.h -> coda_fs_i.h -> fs.h -> everything?)
The allocation overhead really isn't that bad. kmalloc/kfree are also using the slabcache, and a trivial variant using a 'private' slabcache gave me the counters to find the 'leak' I mentioned before.
I can't really evaluate performance impacts. The struct inode is still the same size, so for now there even is a little bit of additional memory pressure. Also, Coda wasn't really developed to achieve high performance but more to explore novel features.
Jan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |