From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <89c5d8771b3e1fafe5b2102ce5f8bb4f@quanstro.net> From: erik quanstrom Date: Sun, 30 Aug 2009 13:53:20 -0400 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Interested in improving networking in Plan 9 Topicbox-Message-UUID: 5c34f712-ead5-11e9-9d60-3106f5b1d025 > Try this - build the source to charon over a 200ms link over 9p. Then > try again over sshfs. why would you do this? why not run the compile closer to the source. this is the power of plan 9. > Also, look at a single terminal with a local fossil install. Trace the > path of an 'ls /'. Count the number of copies and context switches. > > Having the fastest file server in the world means nothing for file > system performance when your path to it is a maze of twisty passages, > all alike. again, this is not a typical install for a performance-sensitive system. and i don't know that anyone ever claimed fossil to be a high-performance file system. running a file system in user space is a matter of convienence, not performance. at coraid, we run a stand-alone ken's file server. ken's file server has no user space. so while there are context switches, those are really speedy. they take maybe a few hundred cycles. the real win is that no data is copied from/to user space and there is one global page table that is never changed. there are no tlb flushes. those can hurt. before the switch to nupas, we averaged 200MB/s of fileserver traffic during the day to >50 clients on a single, fairly pedestrian xeon 5000 machine with 3.5gb of usable memory. perhaps my standards are low and i'm out of touch, but i don't think nfs could do that well with that little. - erik