Rusty is now working for IBM.
Thanks to WatchGuard Inc, and later
Linuxcare. for funding the
netfilter and other work; they are very cool.
Shot off a new proc patch, and a new per-cpu patch just before
going on holidays. Hopefully this way I can avoid the mindless drivel
which follows any /proc work...
And I'm finally updating the Hotplug CPU kernel patch, to integrate
it into my patch collection, at the prompting from guys doing the hard
work (the S390 and ia64 hotplug CPU authors).
To quote one of brighter IBMers I've met:
Alan wants to rewrite the scheduler. I'm glad he's not trying to
maintain 2.4 at the same time then (scheduling, like VM, is among
those things I categorize as "too hard").
It all comes down to the way they number their CPUs; we never had
the problems they saw, mainly though luck: we number our real CPUs
0-3, and their shadows 4-7. They seem to use the lower bit to
differentiate them, although I don't understand Intel APIC stuff.
Maybe I do need to use a stale pointer after all... Hmmm...
The problem is that there are two kinds of refcounting in the kernel:
The dcache fills a dual function: it has "live" entries which are
referred to as working directories, open files, etc, and it has
"cached" entries which are kept around for efficiency. The first set
is fairly easily mapped to a one-based locking system, the second set
needs a separate mechanism, giving us a layering like:
Now I have to implement and benchmark. Personally, I think this
is simpler than what we have now, but I'm used to one-based locking
from the network stuff...
Progress is slow, but I want a complete set of tested patches out
before I go on Friday. Could be long nights between now and then.
Of course, the real reason for the ftp.kernel.org acct is that
Wired, listed me as one of "Linus' Inner Circle" (I'd never read Wired
before, and I don't think I've missed much: the article was fine, but
the magazine as a whole is a bit too k00l for my pedestrian tastes).
Preparing for Linux Kongress next week (I leave on Friday) is
going to mean this is not going to be a very productive few days,
which sucks.
The papers coming in for
linux.conf.au are looking really good: lots of local people doing
cool things I had no idea were being done. I'm starting to really
look forward to it.
Released a tested fix for tcpdumping
while doing NAT. This should work better than my last (untested,
very buggy, got in 2.4.15-pre2) patch.
After months of erum... planning... FHS 2.3 mailing list has moved.
I'll announce the official kickoff to the new list (and a reminder to
the old list) later in the week.
Virtual Anton now works, and is getting more useful as things are
slowly tweaked. The following is the result of mailing "do help" to
Virtual Anton:
Virtual Anton is getting closer to reality.
Good to be working with my peers again.
Now they've opened the door, it'll be interesting to see how far
down the path they go. As Raymond says, it's easy to sell proprietary
software...
But after the debacle with auditing the masquerading pppoe bug (two
audits, a pile of bug reports and a user reporting that commenting out
one call fixed the problem, and I still didn't find
the bug), I've
handed the responsibility for netfilter kernel patches to Harald
Welte.
I've joined Alan Cox's boycott of US conferences, not that that's
hard at the moment, with no time for travel and no conferences in the
US that I want to attend.
Finally got a change to clear my inbox today, for the first time in
months. That feels good.
And you know that EMail about an interactive web page for the
Linux Kernel Graph? He was
interested enough to offer to pay me to create it, so I'll be spending
weekends on that for a while. Results should be cool if you have
enough disk space to host it 8).
However, I've got my in-kernel module linker ported to i86
(trivial), PPC (tricky) and Ultrasparc (easy) so far. I want Alan
Modra to get ELF sections working in PPC-64's gcc, so I can get the
PPC-64 port done. Then, the world! Bwaahahaha....
Someone sent mail asking if there was a web site where you can zoom
in on the Linux Kernel Graph interactively. I replied with my rough
sketch of how I would write such a thing. Wonder if I'll ever hear
from them again?
Looked at using the RCU stuff to speed up the dentry code: the
first step is to get rid of the lock_kernel() Big Kernel Lock which
still haunts these code paths, then we should be able to start cooking
dbench. I thought someone had already done this, but I couldn't find
it in a cursory search.
Hey, and
Thinkgeek started selling the
Linux Kernel Graph
. Cool, only it's kept improving since the one they did (and it's
much faster than it was: only 100 minutes on my laptop now).
Talking with Anand Kumria, the subject of a Global Installfest came
up: wonder if anyone is interested?
I'm hoping this travel doesn't interfere with the work I'm doing on
module loading (in-kernel linking, learning a lot about ELF). I want
to see what the solution looks like: FreeBSD have an in-kernel linker.
It is hard to imagine that it would be as horrible as the locking in
the current module code.
I'm writing the i386 version first, then I'll try PPC and PPC64:
this is in order of difficulty. Particularly since it's going to be
fun to test for subtle bugs (eg. exception tables not working).
Continuing to work on Read Copy Update mainly. Anton showed a 2-3%
improvement on dbench (3GB 4way PPC) by getting rid of the read lock
on fget().
For those interested, see my new random
kernel hacks page .
Wish I had time to see more of the place: went for a quick walk in
the area around the hotel, but we're going back soon. The Australian
Consul (Michael Lynch) said he assumed that Tehran University has a
computer science department: but is there a Linux User Group? And I
have to come back, as I owe the him 20,000 of the local currency.
So many things to do when I get back.
Someone has enhanced the hotplug-CPU patch, and made fixes
(including my missing copy_from_user() which Anton found before).
Expect Anton or I to post an update soon.
Spent most of the day travelling to Aberystwyth (15 minutes
learning how to say it: ab-ber-ist-with). Looking forward to getting
home, now. I must be getting old.
Netfilter-wise, I tested the conntrack race patch, but I only have
my laptop, so it's not a good test. I also have a fix for mtr, which
is in testing. The Brits haven't gotten back to me with travel
arrangements, so it looks like I won't be going to the UK after all.
I'm kind of looking forward to getting home, anyway.
Our rough itinerary is as follows:
But I love being in new places and meeting community people;
there's something unique about a bunch of bits which engenders such
global enthusiasm. They remind me of the TRS-80 User Group (Adelaide
Micro User Group) when I was a kid, except less smoky.
Oh, and cleaned up the conntrack confirmation stuff. This solves
at least one race I can see, and deletes alot of special case code.
The disadvantage is that ipt_REJECT now generates the ICMP errors
entirely by itself.
The good news is, I'm off to Italy for four weeks. Less than one
day a week online, I promise. And after that I'm scheduled to visit
Linuxworld Madrid, Santiago in Spain and Sheffield in the UK.
People are still mailing me about the Linux Graphing project;
attempts to produce for-sale poster versions seem stalled (please
don't EMail me, I really don't care unless you have some for sale).
The Sequent and IBM guys have produced a 2.4.1 patch to add
read/copy/update locks as a first-class citizen to the Linux kernel.
I find their approach over-engineered: such an effort might be
justified if RCU locks were to sweep through the kernel like wildfire,
but I prefer a 6k patch over a 60k patch for the moment.
My approach is to implement synchronize_kernel(), and create an
enhanced schedule_task() which clones threads to allow them to sleep.
This makes implementing a callback mechanism fairly easy, and builds
on existing infrastructure.
Then I'll implement the new module infrastructure on top of this,
and everyone should be happy.
Had a report that 2.4.1 doesn't produce valid postscript. Possibly
a problem continuing halfway through (have some known bugs there), or
could be the parser breaking on some new code.
Friday week I'm in New Zealand; hope to talk at the LUG there (it's
short notice, I know), and I'm going to fly Alli across for the
weekend for us to unwind. After today, I feel like I'll need that.
So, I prepared a page
for it, and sent it out the announce to linux-kernel. Two major
announcements in two days (ignoring the two weeks of work which went
into this previously); not bad.
synchronize_kernel() is slightly different implementation, which
doesn't scale quite as well as the previous, but is less intrusive and
simpler.
I think this irritated Anton.
So I did the infrastructure, and Anton hacked together the
quick-and-dirty low-level routines for the quad PPC box here, and he
send me the following mail today before I got in:
Most of the netfilter fixes I want is in pre-10, the rest sent off
to Linus and DaveM. Tellingly, much of the work here isn't mine,
particularly Harald's IPv6 work.
Been working on the 2.4.0 version of the
Linux Graphing Project ; should be ready for release late next
week. It takes about 12 hours on my 400MHz Mobile Pentium II with
192MB of RAM, because I didn't aim for speed. A few people got a
sneak preview at the conference; this week I printed out a 6x6 A4
sheets version (about 1.1m x 1.5m) after some minor mangling. This
could be classed as a derived work, hence I figure the licence on the
poster is GPL.
Andi and I disagree over implementation; I only skimmed the paper,
and didn't read their code, so I think I have the advantage 8).
More FHS work; I discussed with Alan the /var/www proposal, and he
argued that it shouldn't be normative. So I argued it shouldn't be in
the standard. Then I read
the proposal
again, and it's basically completely non-normative anyway! The FHS
doesn't need more "suggestions".
Since Harald Welte and James Morris were also at the con, we
discussed netfilter-related stuff, of course. The web pages are going
to be checked into CVS, so any team member can update them. I'll
still run the scoreboard for the moment, but I'd like to convert that
over as well, soon. We also discussed what's happening about getting
stuff synced with Linus: bug fixes first, feature ups next, then
finally all the stand-alone modules. Harald is working on sharing the
TCP number information (duplicated in FTP, IRC and other future TCP
helpers) in the core TCP code; he's also offered to enhance the TCP
sequence number tracking patch to cover this core code. We want this
in the next iptables release. Finally we want all the extensions to
be made, even when not installed in that kernel, so distributions ship
them all, and if people compile their own kernels (or new kernels
include the new extension) it'll simply work.
Oh, and got given a gold-plated pewter Tux from
linuxjewelry.com; all the speakers got them.
They're pretty cool; the solid gold ones seem like way overkill
though...
Looking back, it's over a year since I wrote my
Lurker's Tale , which today I'd call
Rusty's Unreliable Guide to the Linux Kernel Mailing List. And it's
as relevent today...
Fixing configuration issues for netfilter in 2.4.1; choosing to be
clever and do FTP helpers as a single option bit me in the Great
Makefile Change. Surprise. Also doing FHS work: another revision
tomorrow I hope.
Finally, I planned to release iptables 1.2 this weekend, but I hit
a failure in the test suite which I'm going to have to track down
first, so delay that a day. If it turns out to be a kernel problem,
I'll have to submit that to Linus...
Hope everyone's coming to
linux.conf.au , because the way that talk is shaping up it can
never go online...
Thursday December 20 2001
Saw some code which didn't use cpu_to_le32() et. al, so I added it to
the Unreliable Guide to Kernel Hacking. Weird though, it actually
evoked a response from Linus.
Thursday December 13 2001
Reworking my "replacement for current /proc of shit" patch to become a
"replacement for current sysctl of shit" patch. Not as cool sounding,
but more accurate. Andi Kleen believes that dentries and inodes are
too large for an in-memory filesystem though, but Linus and Al Viro
like this approach (although it requires deeper understanding of the
dcache than writing a "normal" filesystem).
Wednesday December 12 2001
Phew: I'm glad I rewrote some of those EMails so many times to remove
the vitriol, as I received Alan and Telsa's Christmas card & gift
for when they stayed with us earlier this year.
The flaming doesn't really bother me. I take it as evidence that people
care deeply about getting the right solution. And the fact that (most)
people don't seem to hold grudges is a very good thing. I will take
a technically competent curmudgeon over a cheery and polite airhead any
day of the week!
Tuesday December 11 2001
Started a bit of a flame to see an Intel-specific scheduler patch go
into the kernel. I've been playing with Anton on the scheduler to
support HMT, and the several approaches we've tried have revealed that
it's harder than it looks. Hence my recent work on Mike Kravitz's
multi-queue scheduler, and my abject surprise at a patch which, at
first blush, does nothing useful.
Monday December 3 2001
On the return from Linux Kongress, and the first Netfilter Workshop
which Harald Welte organized. I think we have a good idea on what
will happen in 2.5, most of which already exists in patch form
(although not all in patch-o-matic).
Friday November 30 2001
Stupid Rusty. Last idea for dcache won't work at all, since we can't
make a tree into a one-based reference count system very easily (the
rule with the normal one-based refcnt system is that by the time it's
decremented to zero, there are no pointers to it). This needs much
more thought and some experiment.
Saturday November 24 2001
Anton's been hitting the dcache lock in d_lookup as a bottleneck in
benchmarking. Unfortunately, while this can be made into a read-write
lock (one lock for the lru list, and a read/write for everything
else), that doesn't help: the problem is not contention on the lock
itself, but simply the act of dirtying the lock cacheline. This is
the same penalty whether it is a readlock or a writelock, and it's
only going to get worse with newer chips and larger SMP systems.
We already know how to turn one-based locking into RCU locking, so the
readers don't need to have a lock. However, this is not possible with
zero-based locking. It took me some time to realize the
inherent difference between, say, the dcache and the
route cache, with some help from Al Viro.
Now, we can make the first set a fairly straight-forward one-based
locking system, ie. no locks on d_lookup if we every dentry is live.
The second is a little trickier: we can use a simple hash by parent
pointer and name, IF we always kick children out of the cache before
parents (if we kicked parents out first, then loaded it in again, we
would have a cached entry with the wrong parent pointer, meaning it
wouldn't be found in a cache search). This makes the dentry cache
flushing mechanism a little trickier, but we know how to do fast
threaded lookups on this kind of thing (I don't think we can use RCU
here, but we can definitely do lock-per-hash-chain).
In-use Dentries Recently Used (but not live) Dentry Cache Filesystem Wednesday November 21 2001
Argh. Spent a good couple of days playing with testing my patches,
doing compiles using Virtual Anton to test them, making my "lkpatch"
script work properly for (slightly) intelligent kernel patching, etc.
Sunday November 18 2001
Spent the weekend away visiting Alli's brother, so haven't put
anything up on
my ftp.kernel.org page yet. Thanks to HPA for that: I've been
looking for a place to keep my growing number of kernel patches, and
that's the logical spot.
Friday November 16 2001
More tweaking of Virtual Anton; Anton wanted to say "arch i386 only",
which didn't work. Doesn't quite work yet, but it will soon, with a
bit of a rewrite.
Wednesday November 14 2001
Anton told me that the Sparc64 has to go back to Sun tomorrow. So I'm
in late tonight getting the new module code working on Sparc64 (very
slow work: this is an old Ultra 5 we're talking about).
Tuesday November 13 2001
I proposed to Alli on the weekend. She said yes 8).
Monday November 12 2001
Friday October 26 2001
From: Virtual Anton <vanton@ozlabs.au.ibm.com>
Date: Friday, 26 Oct 2001 10:23:17 +1100
To: Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: do help
X-Virtual-Anton: Virtual Sex God
Message-Id: <20011112231538.3887717F33@haven.ozlabs.ibm.com>
Here is the latest help text
Virtual Anton says: Help? How can I help when I'm trapped in a shell script!
Welcome to Virtual Anton! Version 0.99
Virtual Anton is a mail gateway for (currently Linux Kernel)
patches, which does all the grunt-work of patching, compiling,
testing and benchmarking the results. Virtual Anton runs on a
server, and controls machines as listed in "~vanton/conf/machines".
EMail to vanton contains various commands and (usually) a patch. Commands
are searched for in the Subject line, then the body of the message.
Options are specified in the EMail as follows:
First everything in the Subject line and message body is broken
into sentences, separated by full stops, commas or semicolons.
The each sentence is is evaluated:
If it contains no, don't, dont, or do not, then the sense
of the line is negated.
If it contains skip, ignore, disable, deactivate or avoid,
followed by the option name, it is set to NO (unless
negated above).
If it contains build, enable, activate, add or do,
followed by the option name, it is set to YES (unless
negated above).
Examples:
"do not build ppc" => ppc = NO
"disable ppc" => ppc = NO
"don't enable i386, ppc" => ppc = UNKNOWN (it's on a sentence by itself)
"do not ignore ppc" => ppc = YES
The incoming EMail passes through these stages:
Firstly, if the message contains a "help" parameter (eg. "do
help"), these docs are generated and sent to the user, and nothing
else is done.
Otherwise, for every machine which is not set as NO in the EMail, we want to
build a kernel.
We look in the conf/<machinename>/kerneltree file to see
what the preferred kernel tree(s) is for that machine: they
are tried in order until the patch applies to one and it
compiles, or we run out.
We use the scripts/update-kernel script gathers the latest of that
tree: to add a new tree, modify this script.
The currently available kernel trees are:
haven::ppc64_smp: The OzLabs PPC64 tree, rsyncing the latest from
haven::ppc64_smp for patching against.
alan-cox: This refers to the Alan Cox tree: rsyncing the
appropriate patch from proxy.
linus-pre: This refers to the Linus pre-patches: rsyncing
the appropriate patch from proxy.
development: The latest Linus kernel (including odd numbered).
stable: The latest Linus kernel with an even second digit.
2.2: The latest 2.2 series kernel.
[1-9].*.*: This refers to the any other Linus kernel: patches from
the previous version are rsync'ed from proxy.
For each patched tree, we copy in conf/<machinename>/config, then append
override it using any lines in the EMail beginning with "CONFIG".
Then we feed a set of carriage returns into
conf/<machinename>/make to actually build the kernel.
If a kernel was successfully built for a machine, it is
then tested on that machine, in the background.
First we grab a lock on the machine (to avoid running against other
benchmarks and tests). This can take some time if there is a
queue.
The kernel is then installed on the machine, using the script in
conf/<machinename>/install.
We check that noone is on the machine, using the "w" command: if
there is, the install fails and we send the w output back to the
user.
The boot time required is given (in seconds) in conf/<machinename>/boottime.
We ssh into the machine and run "sudo /sbin/reboot". This means
vanton must have an account on that machine, the ssh keys must be
set up, and we must have permission to run /sbin/reboot via sudo.
Then we transfer most of the Virtual Anton home dir to the machine
(includes the original EMail in tmp/).
Then we run all the tests in ~vanton/tests/ which begin with a
digit, saving the output of each one.
After the tests are run for the machine, we then see if benchmarks
are suppressed in general, (benchmarks NO), or "benchmarks on/for
<machinename>". If they are suppressed, we stop here.
Otherwise we run all the benchmarks in ~vanton/benchmarks/ which
begin with a digit.
If a benchmark succeeds, the output is handed to
scripts/save_benchmark to store in the report subdirectory. This
script must be customized for each benchmark. So far:
dbench results are recorded in full in
dbench-<num>.<machinename>.html, and the final line (the
interesting one), is appended to dbench.list.<machinename>.
Other benchmarks are not saved, and must be added to the
scripts/save_benchmark script.
All these machine tests are happening in the background: if no
kernels were successfully built, for any machine, we simply mail
back that we failed.
Otherwise, we run scripts/create_index, which produces the
index.html from all the scripts/save_benchmark outputs, and/or
failure reports, in the report directory.
So far, we only support dbench results: edit scripts/create_index for others.
If there were any failures, we mail the output of them back to the
user.
Otherwise we simply reply to the user with the URL of the benchmark
results.
Good luck using Virtual Anton!
Thursday October 4 2001
Pulling an all-nighter playing with my config optimizer. Alli's
working night shift tonight.
Sunday September 23 2001
A whole week on the new module code! Luxury!
Monday September 10 2001
First day at IBM today, finally joining most of the ex-Linuxcare guys.
More work on disparate projects to follow in the next few weeks, on my
Titanium Powerbook (finally running non-x86).
Tuesday August 28 2001
Was talking to VA last month, and was stunned and disappointed that
they are becoming a proprietary software company (ie. they are trying
to get rid of their professional services arm, leaving proprietary
software as their only revenue source). How ever much
you spin this, it's
a fundamental shift from a Free Software company to yet another
company which uses Free Software to launch its own products.
Wednesday August 15 2001
I've been working full time (and then some) on the Election System;
it's going pretty well for a software project.
Wednesday July 18 2001
Usually I don't mention this in my diary, but Alli has been sick
recently, so with that and no longer being paid to hack on Linux, I've
been falling way behind in netfilter stuff.
Tuesday July 10 2001
OK, I've been busy with all kinds of non-netfilter things, and there's
been some troubled noises in the netfilter camp. However, I'm pretty
happy to let Harald run with the ball, since he's doing so well.
Monday June 11 2001
Public holiday here today: took some time to look at User Mode Linux,
which seems like a good way to test my in-kernel module linker for
x86.
Monday June 4 2001
Long time, no write. I'm working on the Australian Capital
Territory's Electronic Voting and
Counting System for a while. It's a bit different for me, but
they say a change is as good as a holiday.
Monday May 14 2001
linux.conf.au 2002 looks to be on a good track, but with a date of
early February, it's going to get tight...
Friday May 11 2001
Tomorrow early I head for Brisbane to meet the organizers of
linux.conf.au 2002. Then I'm back for about 24 hours before heading
to Portland, Oregon for a few days.
Saturday May 5 2001
Late night: IRC meeting at 1am. It went fairly well; was quite small.
Good to see all the netfilter members there, and Harald said he's put
the logs online somewhere.
Saturday April 28 2001
2.4.4 is out: recommended upgrade for anyone using the netfilter FTP
module, or running SMP.
Monday April 16 2001
I am in Tehran. Medical emergency forced landing in Iran, and trying
to sort out the takeoff (Lauda do not usually land here) took the
flight crew over maximum hours, so we're in a hotel.
Saturday April 14 2001
Spoke at Aberystwyth, spent Friday sightseeing and hanging out with
Gareth and the others (which was great fun), and Gareth drove me to
Sheffield this morning to speak to
the Sheffield Linux User Group . Which is above and beyond the
call of duty: I hope his car makes it all the way back OK.
Wednesday April 11 2001
Spent a couple of days in Amsterdam, and visited the VA offices in The
Hague; caught up with Wichert Akkerman, with whom I had dinner,
several beers and lots of geek talk later I think we'd covered just
about everything you can imagine. From travelling too much to such
nebulous topics such as "Where Will Debian Go?". It was really fun,
probably the highlight of .nl for me.
Saturday April 7 2001
Now I'm in Santiago, Spain, at
Xuventude Galicia Net ,
which is a big conference/BYO-machine gathering. Lots of cool stuff
is happening here, such as coding competitions, etc. My tutorial here
went pretty well: there were no translators here (unlike
Madrid Linux Expo), so I
added more annotations (most computer people can read English far
better than listen to it), and it seemed to work pretty well: I
preferred it over the Madrid talk, anyway. More questions, and that
always makes me feel more useful.
Wednesday March 14 2001
Well, I'm in Rome, hacking the network code while Alli catches up on
sleep. I've had two of those great Italian coffees, so I'm wide
awake. ("No, no! No americano! Espresso! Si!").
I always feel really bad asking for LUGs to find money to pay flights,
but it's just easier: trying to book reasonably-priced stuff from
Australia is basically impossible (I don't want to pay 500 pounds to
fly from, for example, Milan to Madrid). And I've learnt from
experience that even with airfare and accomodation covered, I spend a
few hundred bucks each trip in airport food, phone calls, hotel
minibars, dinners and money changing.
Thursday March 8 2001
I resigned from Linuxcare on Tuesday; I think my personal direction
and the company direction are increasingly different. I believe the
company has great internal strength and will continue to move forward.
Sunday February 25 2001
Last week I went to Christchurch, New Zealand to do some consulting,
took some personal time with Alison. Had a great time, spoke to a
small group at Christchurch about netfilter et al. Of course, came
back to an overfull mailbox and more work than I know what to do with.
Friday February 9 2001
OK, recovering from the all kernel graph mail. It didn't render on
Red Hat (no tempfile, so 2.4.0a uses mktemp) and now doesn't render on
Slackware (no mktemp). Slackware users can generally figure out the
correct substitution though.
Tuesday February 6 2001
Back to doing the Linux Kernel Graph, finally. I printed and
hand-assembled a 6x6 prototype for the Linuxcare booth at LinuxWorld
NY, but then got distracted away again. Ran it again from scratch
tonight to check it's all OK; after some tweaks it's all working fine.
Mentioned it to Dave Sifry, and he supplied a picture of Linus
standing next to the NY one. Cool.
Monday February 5 2001
A little more tweaking by Anton, and
voila . Of course, the actual
implementation on x86 will take a little longer, but Anton is already
working on UltraSparc support, so we can test it on an E10000...
Sunday February 4 2001
After some brief discussions with people at linux.conf.au about
quiescent points and an off-the-cuff comment to Anton about being able
to use it to hotplug CPUs, some idiot at Microsoft apparently
criticized Linux for not having hotplug CPUs.
From: Anton Blanchard <anton>
Date: Sun, 4 Feb 2001 13:43:49 +1100
To: Rusty Russell <rusty@linuxcare.com.au>
Subject: Re: [PATCH III] With /proc/sys/cpu/NNN stuff...
In-Reply-To: <E14P12N-0000ng-00@halfway>; from rusty@linuxcare.com.au on Sat, Feb 03, 2001 at 10:38:05PM +1100
Hey Rusty,
Check it out!
anton@drongo:~$ ./cpu_crashme 1 &
...
anton@drongo:~$ dmesg | grep Proc
Processor 3 spun down
Processor 3 spun up
Processor 2 spun down
Processor 0 spun down
Processor 0 spun up
Processor 3 spun down
Processor 2 spun up
Processor 1 spun down
Processor 1 spun up
Processor 2 spun down
Processor 3 spun up
Processor 3 spun down
Processor 2 spun up
Processor 1 spun down
Processor 1 spun up
Processor 1 spun down
Processor 3 spun up
Processor 3 spun down
Processor 2 spun down
Processor 1 spun up
Processor 0 spun down
Processor 2 spun up
Processor 1 spun down
Processor 0 spun up
Processor 2 spun down
Now you know you are an idiot
Processor 2 spun up
Processor 1 spun up
Processor 2 spun down
Processor 0 spun down
Processor 2 spun up
Processor 1 spun down
Processor 1 spun up
Saturday January 27 2001
Alan carries a nail punch with him. Alli and I needed one. This is
why he's the Kernel God and I'm the random hacker, I guess.
Thursday January 25 2001
Still discussing the quiescent state stuff Andi Kleen brought up, and
I managed to float past a few people at the con. Keith Owens like the
two-stage module delete (Alexey will be happy, it was his idea). With
the quiescent state stuff it can work quite simply.
Tuesday January 23 2001
Dave M and Nina came down for the day. Dave bought me a `Rusty World
Tour' T-shirt which Alison loves. I'll have to wear it next time I'm
in California.
Friday January 19 2001
Gave my talk today. It was a particularly tough one, since the
organizers had given me a
pseudo-keynote ; normally if the talk is too technical or not
technical enough, you can go to another talk. I had to please
everyone. So the first third was really light, the rest was about
random hacking projects. Was pretty happy with it; I did a fair
amount of preparation, needed because much of the humor depended on
timing statements with the overheads. I think most people enjoyed it;
Alison has now finally seen me speak, too.
Thursday January 18 2001
First non-tutorial day of linux.conf.au .
Some excellent talks; we found a Red Hat Noodle restaurant, and I
managed to convince them to sell me a Red Hat Noodle T-shirt! Small
things, small minds...
Monday January 5 2001
Martin Pool did an emacs lisp routine to speed up scoring. My hero!
Thursday January 11 2001
You know things are bad when you read linux-kernel to relax. Doing
standards is tough. Still, I'm pretty happy over all with the FHS
stuff.
Sunday January 7 2001
Wow, I've been writing (more often, not writing) an online diary for
two years now. I'm sure it'll get interesting soon.
Rusty's 2000 Diary