From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Tue Mar 10 22:28:11 EDT 2020 Received: from stockyard.bk.recurse-network.net (gateway.bk.recurse-network.net [185.230.222.2]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 695a43be (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Tue, 10 Mar 2020 19:28:02 -0700 (PDT) Message-ID: To: plan9fullfrontal@qs.co.nz, 9front@9front.org Subject: Re: [9front] How is smp handled in file services? Date: Tue, 10 Mar 2020 19:28:01 -0700 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: distributed realtime CSS storage persistence realtime-java solution > On 03/11/2020 02:03 PM, ori@eigenstate.org wrote: > > I dont mean to offend , but that seems more than a bit sucky. > > Listening to Rob Pike wax lyrically about the benefits of CSP over > parallel , seems to ring a bit hollow in the face of > all the evidence to the contrary. > (I must admit his metaphor of 'book burning' to explain CSP now looks > quite prescient given the current climate of intolerance to free speech). > > So 15 of my 16 mk tasks come to a shit shattering halt when ever I/O > needs to be done. This explains to me why ramfs does not provide much of > a speed increase when building. > > This probably will translate very badly for performance when file > systems are stacked on top of each other. Rather than achieving > high concurrency , it will degenerate into a linear flow through the > stack and back. > > Probably also explains why 9p over the interweb is so slow. > > What I don't see in the 'Plan' is how to introduce a pipeline into the > Fileserver processing to take advantage of SMP. Even if you > break each I/O request into 10 steps, there is no way to separate this > out into 10 programs all working concurrently. So as you say > each file service has to make it's own determination on how many tasks > to run concurrently, which is also sub-optimal. > > The design of P9 is to have FS in userspace and not kernel so > optimizations there are not going to help. Disk file systems like cwfs tend to be fairly parallel. Code can't be automatically parallelized, you need to write it that way. Using CSP if you like. As for latency -- this is due to design choices in 9p that will need to be fixed at some point, and adding parallelism in the file server won't help.