Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: FLAME ON: Re: Sun bogosities, including MMU thrashing Message-ID: Date: 11 Feb 91 22:04:21 GMT References: <5257@auspex.auspex.com> <3956@skye.ed.ac.uk> <399@appserv.Eng.Sun.COM> <417@appserv.Eng.Sun.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 80 Nntp-Posting-Host: teachk In-reply-to: lm@slovax.Eng.Sun.COM's message of 5 Feb 91 10:16:52 GMT On 5 Feb 91 10:16:52 GMT, lm@slovax.Eng.Sun.COM (Larry McVoy) said: lm> Ready flame throwers, take aim, .... fire! It's snowing out there -- thanks for the warmth :-). lm> In article pcg@cs.aber.ac.uk lm> (Piercarlo Grandi) writes: pcg> Even more bizarre, I have seen an article about some other McVoy pcg> (the evil twin? :->) reporting that he (or she) has just published pcg> a paper in lm> I'm the evil twin. I'm me. I happened to know that. Wasn't fooled by a little NNTP bogosity. I was just teasing you (and your evil twin :->) a bit. Idle minds tend to be a bit pukish. lm> Me@berkeley is thanks to xrn that thinks the entire world consists lm> of the Berkeley.edu domain. A bit provincial, that. Just have a chat with your postmaster about what happens to From: lines that happen to pass thru Sun.COM. Tsk tsk. Probably UCB are just retaliating in kind. Header wars! :-). In the following (a little more technical than the previous one! not at all offensive! I wish all flames were like this!) posting I have trimmed a lot of your points that are not essential (I have regrettably given little attention to non sequential IO), barely suppressing my urge to gnaw at them too. But before going into the bloody long detail, here is a summary in a couple dozen lines: Central to our argument is whether better performance transferring (sequentially) a given amount of data is obtained by having large IO transactions and a FIFO queue size of two or by having small transactions and a variable (usually small, but possibly larger than two) queue size. Example: is it better to read 128KB as one synchronous 56KB transaction plus one asynchronous 56KB one, or as one synchronous 1KB transaction plus N asynchronous 1KB ones? Larry McVoy advocates something like the first alternative, claiming that in practice he gets better benchmarks times with 56KB+56KB (actually he thinks that this is a bit excessive, and would be happy with lower values), and I claim that 40 years of computer science research conclusively demonstrate that 1KB+N*1KB is better, and that N can be fairly small (even if usually 1 is good, according to Knuth, as the Unix authors knew), offering detailed examples. I also claim that even 8KB+8KB is bad because the finer is the block/page granularity the greater the adaptability to fine granularity files (median sizes around 1KB and in any case under 4KB) and to extremely variable loads (spanning three orders of magnitude) while performance need not suffer because dynamic clustering can be employed *if* needed, while Larry McVoy reckons that coarser granularity and static clustering wins most of the time and the rest doesn't matter much. In other words I say that with 8KB+1*8KB (even worse for 56KB+56KB) the 8KB granule is too large, or rather not as small as it could be, and the 1 read ahead may be either too *small* or too large, depending on highly variable contextual conditions. I also try to show that the better benchmark times experienced by Larry McVoy depend on larger IO transaction sizes obviating some bogosity in SunOS, not on their intrinsic value, and also depend on the assumption of unlimited real memory, as in his given example of a kernel build on a 32MB machine. I observe that these two assumptions explain the benchmarks, help the Sun bottom line, and explain why nobody complains -- just pop in more memory, and the bogosities are circumvented, even if not solved, just like raising the number of MMU cache slots. The full discussion will appear as a separate article, with a subject line like "A treatise on ... " :-). -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk