25 Oct
2017
25 Oct
'17
2:51 a.m.
I've always enjoyed this paper; recently I found occasion to thumb
through it again. I thought I'd pass it on; I'm curious what some on
the list think about this given their first-hand knowledge of relevant
history (Larry, I'm looking at you; especially with respect his
comments on the VM system).
- Dan C.
http://www.terzarima.net/doc/taste.pdf
25 Oct
25 Oct
3:14 a.m.
I'm in the middle of a family medical thing, I glanced it this, it looks
like it has merit. Give me some time, if I'm the Larry you meant, maybe
I'm yapping and I have no place to be talking. I'll give it a read either
way, I love stuff like this.
On Tue, Oct 24, 2017 at 10:51:17PM -0400, Dan Cross wrote:
I've always enjoyed this paper; recently I found
occasion to thumb
through it again. I thought I'd pass it on; I'm curious what some on
the list think about this given their first-hand knowledge of relevant
history (Larry, I'm looking at you; especially with respect his
comments on the VM system).
- Dan C.
http://www.terzarima.net/doc/taste.pdf
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
26 Oct
26 Oct
5:27 p.m.
On Tue, Oct 24, 2017 at 10:51:17PM -0400, Dan Cross wrote:
I've always enjoyed this paper; recently I found
occasion to thumb
through it again. I thought I'd pass it on; I'm curious what some on
the list think about this given their first-hand knowledge of relevant
history (Larry, I'm looking at you; especially with respect his
comments on the VM system).
- Dan C.
http://www.terzarima.net/doc/taste.pdf
OK, I've read it. This could have been a great paper if he had included
some performance results. As it is, I'm sorry that his ideas didn't take
hold, or at least get some discussion.
The paging stuff is neat but it doesn't address the file system page cache
so far as I tell. It's process based so unless the process had the file
mmap-ed it wouldn't take care of it. And mmap didn't exist at the time,
so I'm not sure how he handed the page cache.
He was fixated on code size, and yeah, on 4MB machines, you need to
be even on 8 you need to be (at Sun we called EMACS Eight Megs And
Constantly Swapping). But I'd like to know if his paging scheme worked.
I went through a period where I wrote over a dozen different pageout
daemons in an effort to do a better job; none did. They had certain
use cases where they did better but then other work loads made them
perform worse. That global pageout daemon is still around, it's
depressingly hard to do better than that. If he succeeded it would
be nice to have numbers.
His pageout scheme could have all forward pointers if he had them in
the vnode along with the process.
I agree with him on fork, there is no reason not do do vfork in fork
that I can think of (other than wnj's hack of putting stats in the
parent process by the child in csh and that was just gross).
His comments on the file system switch vs VFS sort of miss the point
that the VFS was put in place to allow file systems that don't have
Unix semantics (NFS being the biggest example). But I agree that
there perhaps could have been a better approach, this is why it
would have been nice to have his stuff get a broader audience.
I disagree on the streams/STREAMS stuff, that shit has no place in
anything that wants performance. I'm working with netflix, trying
to do better than this:
https://news.ycombinator.com/item?id=15367421
which is a discussion of their writeup of how they managed to push
~100Gbit/sec of movies on a single machine. Sticking STREAMS in the
middle of that was a bad idea back in the day and a worse idea today.
But all in all, an interesting paper. It's pretty amazing how many of
the people in the references I know, lots of them I've worked with, Steve
Kleiman was my mentor at Sun, Rosenthal and I had tons of OS discussions.
I toyed with going to HP Labs to work with John Wilkes, etc. Definitely
a trip down memory lane and makes me feel super lucky to have gotten to
work with people of that caliber.
Thanks for the pointer.
--lm
10:12 p.m.
I worked with Charles in the University of York. he's the guy who said
to me "how can it be simple, if the printout is half an inch thick"
about SMTP.
Charles also enjoyed himself: fancy dress, he had a full on Sun-King
court suit made, to go with his huge head of hair. This, in york, a
city of red-brick terraced houses, back-to-backs, and beer. Louis XIV
walking down t' road for a pint...
I think when he implemented streams in one or two pages of text from
the BLTJ article, and then sighed at the size of STREAMS when it came
to life.. says it all. he was very very strong on a reductionist
'size matters' world view. His editor of choice in 1984 was ed, with a
command macro to repaint -22 + 22 about the . line.
(I hasten to add, Charles and I worked in totally different areas, and
I use the term "worked" in regards to myself with some trepidation)
On Fri, Oct 27, 2017 at 3:27 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Tue, Oct 24, 2017 at 10:51:17PM -0400, Dan Cross
wrote:
I've always enjoyed this paper; recently I
found occasion to thumb
through it again. I thought I'd pass it on; I'm curious what some on
the list think about this given their first-hand knowledge of relevant
history (Larry, I'm looking at you; especially with respect his
comments on the VM system).
- Dan C.
http://www.terzarima.net/doc/taste.pdf
OK, I've read it. This could have been a great paper if he had included
some performance results. As it is, I'm sorry that his ideas didn't take
hold, or at least get some discussion.
The paging stuff is neat but it doesn't address the file system page cache
so far as I tell. It's process based so unless the process had the file
mmap-ed it wouldn't take care of it. And mmap didn't exist at the time,
so I'm not sure how he handed the page cache.
He was fixated on code size, and yeah, on 4MB machines, you need to
be even on 8 you need to be (at Sun we called EMACS Eight Megs And
Constantly Swapping). But I'd like to know if his paging scheme worked.
I went through a period where I wrote over a dozen different pageout
daemons in an effort to do a better job; none did. They had certain
use cases where they did better but then other work loads made them
perform worse. That global pageout daemon is still around, it's
depressingly hard to do better than that. If he succeeded it would
be nice to have numbers.
His pageout scheme could have all forward pointers if he had them in
the vnode along with the process.
I agree with him on fork, there is no reason not do do vfork in fork
that I can think of (other than wnj's hack of putting stats in the
parent process by the child in csh and that was just gross).
His comments on the file system switch vs VFS sort of miss the point
that the VFS was put in place to allow file systems that don't have
Unix semantics (NFS being the biggest example). But I agree that
there perhaps could have been a better approach, this is why it
would have been nice to have his stuff get a broader audience.
I disagree on the streams/STREAMS stuff, that shit has no place in
anything that wants performance. I'm working with netflix, trying
to do better than this:
https://news.ycombinator.com/item?id=15367421
which is a discussion of their writeup of how they managed to push
~100Gbit/sec of movies on a single machine. Sticking STREAMS in the
middle of that was a bad idea back in the day and a worse idea today.
But all in all, an interesting paper. It's pretty amazing how many of
the people in the references I know, lots of them I've worked with, Steve
Kleiman was my mentor at Sun, Rosenthal and I had tons of OS discussions.
I toyed with going to HP Labs to work with John Wilkes, etc. Definitely
a trip down memory lane and makes me feel super lucky to have gotten to
work with people of that caliber.
Thanks for the pointer.
--lm 
27 Oct
27 Oct
3:49 a.m.
On Fri, 27 Oct 2017, George Michaelson wrote:
I worked with Charles in the University of York.
he's the guy who said
to me "how can it be simple, if the printout is half an inch thick"
about SMTP.
Charles also enjoyed himself: fancy dress, he had a full on Sun-King
court suit made, to go with his huge head of hair. This, in york, a
city of red-brick terraced houses, back-to-backs, and beer. Louis XIV
walking down t' road for a pint...
This is that guy who did the clone of the v7 Bourne shell that used to be
used in Minix and PicoBSD and was the basis of pdksh?
(There was, actually, a Korn shell clone for MS-DOS and OS/2 based on it.)
I think when he implemented streams in one or two
pages of text from
the BLTJ article, and then sighed at the size of STREAMS when it came
to life.. says it all. he was very very strong on a reductionist
'size matters' world view. His editor of choice in 1984 was ed, with a
command macro to repaint -22 + 22 about the . line.
I personally believe a lot of code in modern operating systems is larger
than the task requires.
-uso.
6:55 a.m.
Steve Nickolas <usotsuki(a)buric.co> wrote:
On Fri, 27 Oct 2017, George Michaelson wrote:
Yes.
Charles is still very active in the Plan 9 world. I don't know if he
still prefers ed over sam or Acme though. :-)
Arnold
I worked with Charles in the University of York.
he's the guy who said
to me "how can it be simple, if the printout is half an inch thick"
about SMTP.
....
This is that guy who did the clone of the v7 Bourne shell that used to be
used in Minix and PicoBSD and was the basis of pdksh? 
7:30 a.m.
On Thu, Oct 26, 2017 at 10:27:35AM -0700, Larry McVoy wrote:
OK, I've read it. This could have been a great paper if he had included
some performance results.
Well, once could always ask him if he still has such; since he tends to hang
out on the 9fans list. I believe his address may be charles.forsyth(a)gmail.com,
(but I don't have a recent message to verify against).
DF
9:44 a.m.
He last posted from that address on 18th October.
d
On 27 Oct 2017, at 18:30, Derek Fawcus
<dfawcus+lists-tuhs(a)employees.org> wrote:
On Thu, Oct 26, 2017 at 10:27:35AM -0700, Larry McVoy wrote:
OK, I've read it. This could have been a great paper if he had included
some performance results.
Well, once could always ask him if he still has such; since he tends to hang
out on the 9fans list. I believe his address may be charles.forsyth(a)gmail.com,
(but I don't have a recent message to verify against).
DF
2372
days inactive
2374
days old
7 comments
7 participants
participants (7)
-
arnold＠skeeve.com -
Dan Cross -
David Arnold -
Derek Fawcus -
George Michaelson -
Larry McVoy -
Steve Nickolas