On 3/19/06, Eric Lowe <[EMAIL PROTECTED]> wrote: > Holger Berger wrote: > >> I wasn't directly involved in the 64K prototype but only 64K and larger > >> were used for user applications, and the page_t was 64K in span > >> (PAGESIZE=65536). There may have been some 8K mappings in the kernel due > >> to OBP handing off translation lists with holes -- I don't remember the > >> details there. > > > > Who was involved in this project? > > I don't believe any of the folks involved directly are active in > OpenSolaris yet, so to avoid having vegetables thrown at me I won't say. :)
Maybe the project lead at Sun is willing to comment here. Could you ask him, please? > > Did you receive any answers yet? I'd like to write a project proposal > > for a 64k kernel project - assuming Sun is willing to release the > > sources of their original prototype. > > Great -- by all means, go for it! First I'd like to ensure that Sun is willing to contribute the code. A project without a basis is useless. > We'll need to figure out which community should own this project > long-term. We've been reluctant to build a VM community because several of > us feel that a broader kernel community would better facilitate open > discussion and collaboration, yet such a community would have significant > overlap with existing communities, so that still needs some sorting out. > For the time being, I think the Performance community would be a good home > for it -- check with the leaders. Ok. perf-discuss@opensolaris.org is now in the CC: :-) > I did check into the source issue a little but haven't had the bandwidth > to investigate the details yet. The old project gate is based on S9, so we > can't just "toss it over the wall". If you're open to a partially complete > starter solution to seed the work, i.e. which doesn't quite boot and run > on all machines but has most of the right areas at least fleshed out, that > would probably be much easier for me to push for on my end. I'd be happy if it boots at least via NFS or could be adjusted to boot via NFS quickly. > > It depends on the application. For the majority of smaller and medium > > sized applications such as FEM 64k pages have a serious advantage. I/O > > operations are limited by dwarfpages, too. MPSS buys nothing in this > > case. > > Our whole kernel I/O subsystem is not large page aware, which is something > that clearly needs work, you're right about that. (And, the fact that the > bus nexus internal interfaces are all page-based is a perfect example of > why this is so hard to change!) The kernel I/O subsystem does not need to be large file aware. The minimum page size changes from 8k to 64k. By design and definition 64k pages will no longer be "large pages" at all. This is why I think much less work needs to be done as you think. UFS may need work, MMU core code needs adjustments for the 8k-to-64k transition (see earlier comments) and some tunable need to be changed. That is all for now on the To Do list. -- Holger _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
