Messages in this thread | | | Date | Thu, 29 Jul 1999 15:04:25 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: clustering page-ins |
| |
On Thu, 29 Jul 1999, Jamie Lokier wrote: > Chuck Lever wrote: > > true. but i'm also worried about sharing the read-ahead information > > amongst all mappers of a shared file. this case has come up in my > > benchmarking (although i haven't tracked it down, it is occurring in some > > basic commands that are run by the benchmark). > > Since each mapping has its own vm_area, I don't see the problem. > Do you want different mappers to share read-ahead info?
yes, since they are sharing the same file in the same page cache it would be silly to trigger read-ahead needlessly, even if it finds all the pages already in the page cache.
> > so, i think the information needs to be in the file struct so that shared > > maps don't continue to read ahead a file that is already in the page > > cache. > > Sorry I don't quite understand what you want here. If you want to share > read-ahead info between different mappers, struct file isn't going to do > it -- each new open() creates a new struct file. If you don't, vm_area > and struct file won't make much difference.
> It's only when you consider multiple mappings made from the same file > descriptor (or passed through fork/exec) that there's a difference: then > struct file leads to sharing while vm_area does not. There's also the > matter of files mapped and read with read() (e.g. ELF executables).
so perhaps a better place to put read-ahead context is in the file's inode.
- Chuck Lever -- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |