Date: Thu, 3 Oct 1996 14:18:57 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@render.com (Doug Rabson) Cc: heo@cslsun10.sogang.ac.kr, freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org Subject: Re: vnode and cluster read-ahead Message-ID: <199610032118.OAA06789@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95.961003181143.10204U-100000@minnow.render.com> from "Doug Rabson" at Oct 3, 96 06:18:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I suggest a new idea. The fields for read-ahead(maxra, lenra, etc) > > are in file structure or other structure(e.g. Doug Rabson's readahead > > structure) that is pointed by a new field in file structure. And > > vnode has a new field to contain the point to the file structure. > > This vnode field is filled every read system call with the point > > to the file structure at vn_read() in kern/vfs_vnops.c Then it is > > possible that the file structure is accessed through vnode in > > cluster_read. > > Not all the vnodes in the system are associated with file structures. The > NFS server uses vnodes directly along with some other oddities like exec > and coredumps. If we optimise cluster_read for normal open files, we > should try and avoid pessimising it for other vnode users in the system. To deal with this, you would have to add a "read ahead hints parameter" to the thing, and for NFS, pass one that will result in no change in the algorithm. This might be a good thing, but it would require minor changes to huge amounts of kernel code. In addition, it is not clear that the reverse mapping could be successful; you could change a vnode pointer on call down, but it would mean that you have destroyed call reentrancy for the interface, since reentering on the same vnode would potentially blow the same field before the downcall code could use it. Again, moving to a parameter instead of a vnode encoding would fix this, at possibly unacceptable cost. > I have vain hopes of a future kernel which is multithreading and > introducing a new complication to that is not a good idea IMHO. In > addition, multiple userland threads could fool a system where readaheads > were calculater per-open-file. I agree. In addition, moving to an async call gate to implement threading, where you make the same call through a different trap entry point, and potentially blocking operations automagically generate an async context record plus a context switch, would definitely tickle this problem. > > This method removes the hashing using vnode and block number. > > For the common single reader case, the vnode would cache a pointer to the > readahead structure, avoiding the hash. The hash would be a simple O(1) > operation anyway for the multiple reader case and so should not be a real > performance problem. I agree again. You either trust cache locality to work, or we might as well through out all caching, since we should measure all algorithms by the same yardstick. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610032118.OAA06789>