From: Matthew B. <ma...@by...> - 2002-11-08 09:21:52
|
On Friday 08 November 2002 07:31, Steve Schnepp wrote: > En réponse à Jeff Dike <jd...@ka...>: > > Eliminating the UML caching would be bad. You really want to force > > UML to do IO to the host on every file IO? > > Yes, why whould that be a problem ? The host can happily decide not > to do real IO on the device, based on its MM rules. > My solution is maybe not optimal when only one UML is running, but with > several i hoped that the host is smarter than the UMLs since he has a > global vision. > > Anyway, i stop debate here since i don't have any facts to show to > you. I'm investigating the case further anyway, and i might come > up with a full study ;-) I'm interested in this too: I'd have thought that a process is wasting its time trying to cache disc blocks when its running on top of a kernel that's doing the same thing? At least I'd have thought it would be wasting memory: I was under the impression that the Linux kernel (both i386 and UML) used all its available memory as a disc cache. So why restrict the host kernel's ability to cache disc blocks, because it can surely do a better job knowing about all the disc blocks that all its processes need access to than one process thinking about its own blocks? Please tell me if I have my facts wrong: I'm also curious to know why forcing O_DIRECT on file opens within a UML would lead to a loss in efficiency. -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026 |