From 4e845679ff5f73fcfd291d6b88af0c6753b65015 Mon Sep 17 00:00:00 2001 From: Murray Stokely Date: Fri, 16 Aug 2002 07:27:20 +0000 Subject: [PATCH] Add hyperlinks from the agenda items to the sections of the transcript that cover that topic. Also clean up the HTML at places, and add more markup. --- en/events/2002/usenix-devsummit.sgml | 147 ++++++++++++++++----------- 1 file changed, 90 insertions(+), 57 deletions(-) diff --git a/en/events/2002/usenix-devsummit.sgml b/en/events/2002/usenix-devsummit.sgml index 0a35c67d0c..ef7b3090f2 100644 --- a/en/events/2002/usenix-devsummit.sgml +++ b/en/events/2002/usenix-devsummit.sgml @@ -1,7 +1,8 @@ - + +
BREAK
'> %includes; @@ -29,17 +30,17 @@ Stokely.

NOTE: As usual I missed some names, please add those I missed.

@@ -93,6 +94,7 @@ Stokely.

+

KSE - Julian Elischer

KSE has not changed much since the last summit (Feb). The major @@ -240,21 +242,26 @@ the Solaris ABI.

+

SMPng - John Baldwin

-

JB : Yesterday we talked about SMP related things so I'll give a summary -and then give a list of things for 5.0. +

-

JB : The big thing for 5.0 is to get the network stack out from under -Giant. +

JB : Yesterday we talked about SMP +related things so I'll give a summary and then give a list of things +for 5.0.

-

JB : Jefferey Xu and Jennifer Ying were here to talk about this. They -have the PCBs checked in now. +

JB : The big thing for 5.0 is to +get the network stack out from under Giant.

-

JY : Interface Queues and SynCache might be done. +

JB : Jefferey Xu and Jennifer Ying +were here to talk about this. They have the PCBs checked in now.

+ +

JY : Interface Queues and SynCache +might be done.

+

The remaining chunks of the network code are:

-
  • Routing Table Locking
    • @@ -266,6 +273,8 @@ have the PCBs checked in now.
  • Netgraph
+
+

JB : Aside from network the newbus locking needs to be done (Warner Losh) and also CAM stuff. No known status on CAM. Perhaps CAM is not needed for 5.0

@@ -286,64 +295,78 @@ memory is a socket its a socket forever, this is no longer true.

5.0 and have decided to stop adding features so that we can start clean up 5.0 and make it a real release. This might require hacks.

-

RW : For example in the UMA case there could be a flag to just say -"don't reclaim this zone" -- this would help with issues such as the -socket code assuming memory is type stable. +

RW : For example in the UMA case +there could be a flag to just say "don't reclaim this zone" -- this +would help with issues such as the socket code assuming memory is type +stable.

-Over to AC on the VM system. Nothing to say. +

Over to AC on the VM system. Nothing to say.

-

BM : As much as I might get hated for this. Will preemption stuff -go away by 5.0? +

BM : As much as I might get hated +for this. Will preemption stuff go away by 5.0?

-

JB :No, that's a 6.0 thing. There are things to do first. +

JB :No, that's a 6.0 thing. There +are things to do first.

-

??? Phone : Could this come in in the life time of 5.? 5.1? +

??? Phone : Could this come in in +the life time of 5.? 5.1?

-

RW : This is a release issue really. +

RW : This is a release issue really.

-

JB : Yes, the kernel is pre-emptive. +

JB : Yes, the kernel is pre-emptive.

-

RW : Perhaps we should talk about is performance goals? What are the -comparisons to make? Perhaps head of 4 with head of 5. We'll see a -mix. +

RW : Perhaps we should talk about +is performance goals? What are the comparisons to make? Perhaps head +of 4 with head of 5. We'll see a mix.

-

JB : I need to run benchmarks. +

JB : I need to run benchmarks.

-

RW : In terms of SMP features when will VM be ready to be measured? I -can't put a date on it. +

RW : In terms of SMP features when +will VM be ready to be measured? I can't put a date on it.

-

AC : I think I told John was in time for release. I'm already doing -performance testing so we've already started. +

AC : I think I told John was in +time for release. I'm already doing performance testing so we've +already started.

-

RW : We'll pick a date to start doing measurements. Perhaps 2 or 3 -weeks from now. +

RW : We'll pick a date to start +doing measurements. Perhaps 2 or 3 weeks from now.

-

AC : My guess is the the locking pmap is going to take some time to -shake out. On the other hand the next major module we should be -working on is machine dependent level. Last we should try approaching -the vmobject level. I'll start worrying about performance in the near -term. +

AC : My guess is the the locking +pmap is going to take some time to shake out. On the other hand the +next major module we should be working on is machine dependent level. +Last we should try approaching the vmobject level. I'll start +worrying about performance in the near term.

-

RW : Will threading improve latency or throughput for networking? +

RW : Will threading improve +latency or throughput for networking?

-

BM : I would like if we could actually start before. +

BM : I would like if we could +actually start before.

-

RW : Do you have a timeline for the interrupt threading stuff? +

RW : Do you have a timeline for +the interrupt threading stuff?

-

BM : I finished some things last night but there are still issues. -In a couple of weeks it should be ready for first commit. +

BM : I finished some things last +night but there are still issues. In a couple of weeks it should be +ready for first commit.

-

RW : Informally beginning to measure performance now. What are the -right sets of tests? Need to discuss on -arch. +

RW : Informally beginning to +measure performance now. What are the right sets of tests? Need to +discuss on -arch.

-

AC : It would be nice to have that committed to the tools directory. +

AC : It would be nice to have that +committed to the tools directory.

-

JB : The statistics analysis package are we using. +

JB : The statistics analysis +package are we using.

-

BM : I have some good success with netpipe for overall measurement. +

BM : I have some good success with +netpipe for overall measurement.

-

RW : Need to be using consistent compilers because of the compiler -change. Also all our debugging stuff will slow down the benchmarking. +

RW : Need to be using consistent +compilers because of the compiler change. Also all our debugging +stuff will slow down the benchmarking.

+

Benchmark Ideas

    @@ -376,6 +399,8 @@ change. Also all our debugging stuff will slow down the benchmarking.
  • slow/fast CPU
+
+

MD : Debug stuff on 5.0. I think it might be reasonable then to take the space hit and always have the debugging in but turn it on and off with sysctl.

@@ -383,10 +408,11 @@ debugging in but turn it on and off with sysctl.

RW : We should commit an optimized kernel configuration and benchmarking guidlines to the tree as well.

+
-
-BREAK -
+&break; + +

RW : I think we should continue the performance discussion. We want to accomplish a couple of things. @@ -468,9 +494,11 @@ the project though.

RW : I will set up the mailing list.

+
+

New Hardware Architectures

Alpha

@@ -629,7 +657,7 @@ LUNCH
- +

Trusted BSD

RW : MAC framework is what is of @@ -675,6 +703,7 @@ stuff that's not done yet.

+

Release Engineering

MS : Shows a slide of releases. @@ -890,8 +919,11 @@ come release.

+&break; +
+

rc.d

@@ -960,6 +992,7 @@ system.

+

Other Issues