"Neal H. Walfield" <[EMAIL PROTECTED]> writes: > Your other comments basically made sense, however, in the context of > this statement, I have become extrememly confused. So, before I react > to your other comments, I would like you to elaborate what you mean by > this statement. Specifically, what about my proposal does not happen > in user space? What I suggest (and what Ogi has basically > implemented) are changes to libpager (in the form of adding > pager_notify_eviction) and modifying ext2fs to only map active > metadata. Nothing about this involves changes to the kernel; nothing > I propose involves using undocumented features; everything I suggest > functions within the Mach 3 framework.
Yes, my mistake; I was confusing it with a previous misunderstanding I had! Geez, this is what happens when I don't sleep enough. What I really mean is that I can see no good reason to break the basic structure of the memory object model. For example, there is no good reason to assume that the filesystem runs its own pager: in fact this is really a mistake. A much better design would have the disk driver pager be used, and not the filesystem's at all. The only reason we can't do that is because we need to control to deal with the file data pagers, especially since the same disk block might be file data one day, and metadata (an indir block) the next. So what a nice interface would be (starting over in the design of Mach) would allow multiple pagers to own a single memory page in some fancy ass way. Failing that, we have to lump the two pagers into one program to get the necessary control. But I think it's a mistake to take such heavy advantage of that control, and it seems somewhat brittle to me as well. The only argument in favor of this proposal that I can see is that if the paging tables in the kernel are unpageable, and if they are really big, then my version might suck. But I don't think that's a big factor, because they are pageable, and because I don't think they are so big anyway. There is a disadvantage of my proposal which is the number of extra memory objects that have to be kept track of: because it's an array of memory objects, not just one, it might use more resources that way. But on the other hand, your version suffers (in my opinion very severely) because you basically can't allow the kernel to cache data. You have taken over the caching policy for the kernel. Since the assumption we operate under is that the kernel can do better caching than any user process (because it has a global view of the resource situation) we don't want user processes taking over caching of the actual disk data. But because you must purge the data from memory any time you remove the mapping, you now must think up a caching strategy, compare it with the real ones in the kernel, and make sure it interacts well. By contrast, mine also requires a caching strategy, but it is only a caching strategy for memory mappings, which, unlike core, are not a limited globally shared resource. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
