OLS 2004
The call
for papers ends today. I have decided not to submit a paper
this year. I need to be spending more time writing code and less
time talking about it.
Kernel Workshop
.. and with that in mind, I’m going to be giving a one day Linux
Kernel workshop today. The slides and code are available on my
talks page. I
didn’t have nearly enough time to prepare it, but I hope it will
turn out well.
Life
Last night, before I went to sleep, I felt myself sliding into
depression. Is it possible to slide out of depression?
Muli Ben-Yehuda's journal 
I hope it is possible. I had a slight depression two nights ago. It was quite bad actually.
Saw your slides. Looks good.
Comment by ideawerkz — March 14, 2004 @ 8:30 PM |
Thanks. I hope you feel better (I do, a good night’s sleep always does it for me).
Comment by mulix — March 16, 2004 @ 12:01 AM |
Just returned home. Feeling a little better. Time to start re-compiling historical (2.4.9/10) kernels. Wish me luck. Still can’t it compiled yet.
Comment by ideawerkz — March 16, 2004 @ 3:50 AM
That sounds like fun (not). Good luck!
Comment by mulix — March 16, 2004 @ 5:19 AM
Got it to compile, and boot. Time to port my patch.
Comment by ideawerkz — March 16, 2004 @ 5:41 AM
off topic
So I actually found a use for your syscalltrack thing today, finding what program keeps fork()ing every couple of seconds on my system (gkrellm shows that something is spawning, but I can’t figure out what). I wish syscalltrack didn’t require building another kernel module, since I don’t really want to do that. Do you know of any other way to figure out what process keeps spawning?
Comment by compwiz — March 15, 2004 @ 9:12 AM |
Re: off topic
write a small program that walks /proc/pid, looking for new processes and noting their parents pids? then build a process tree, which should make it fairly obvious which program is at fault. Note that you need to be walking /proc/pid faster than new processes are spawned, but if it’s only every couple of seconds, it should be trivial.
Comment by mulix — March 16, 2004 @ 12:08 AM |
Re: off topic
the problem is that whatever process spawns & goes away too quickly to see it with top or ps aux, so I’m not too sure that will work.
Comment by compwiz — March 16, 2004 @ 5:39 AM
Re: off topic
hijack the fork routine, and then redirect it to a proc or a file. should be pretty trivial.
Comment by ideawerkz — March 16, 2004 @ 9:00 AM
Re: off topic
hijacking the fork routine requires either changing the kernel (which he doesn’t want to do), or modifying a running process (unless it’s reproducible? I was amusing it isn’t)…. not quite that trivial 😉
Comment by mulix — March 16, 2004 @ 9:26 AM
on
oh, and isn’t NPTL Native POSIX Threads Library, not New POSIX Threads Library?
Comment by compwiz — March 15, 2004 @ 9:13 AM |
Re: on
Native, correct. Thanks, will be fixed in a moment.
Comment by mulix — March 16, 2004 @ 12:09 AM |
Oh, and the version of syscalltrack in Debian is wayyyyy out of date. You might want to push Baruch to update it.
Comment by compwiz — March 15, 2004 @ 9:26 AM |
I don’t think Baruch is maintaining it any more, but I’ll ping him just in case. Thanks.
Comment by mulix — March 16, 2004 @ 12:09 AM |
Why isn’t Baruch maintaining it? Btw, is it a lot of trouble to maintain it? If not, I wouldn’t mind adopting it from next month onwards.
Comment by ideawerkz — March 16, 2004 @ 9:00 AM
I guess he’s busy. I dont’ know if it’s a lot of trouble, but it’s definitely not a trivial package (kernel patch, etc).
Comment by mulix — March 16, 2004 @ 9:25 AM
Even rml’s procps is not trivial. I had a hard time packaging it… I did it half-way, and have to put it aside because it is taking up too much time at the moment.
Nothing is trivial. If it is trivial, I shouldn’t be awake now 🙂
Comment by ideawerkz — March 16, 2004 @ 9:33 AM
procps 3 is at procps.sf.net
You need procps 3 anyway for recent kernels.
See http://procps.sf.net/ for the 3.2.1 release
or whatever else is current when you get there.
Comment by Anonymous — April 18, 2004 @ 8:51 PM
Re: procps 3 is at procps.sf.net
There are two branches to procps. One is from the link you gave, the other one is by some kernel developers I know. The latter have some tools that I need for development, thus it is more useful.
Btw, who is this?
Comment by ideawerkz — April 18, 2004 @ 9:08 PM
Re: procps 3 is at procps.sf.net
This is Albert Cahalan. I did write the /proc thread support in the 2.6.xx kernel,
which counts as kernel development I think. The most recent release contains
slabtop — is that what you refer to? Here’s what procps-3 gives you:
* ps fully supports thread display (H, -L, m, -m, and -T)
* ps can display NSA SELinux security contexts
* handles pts/* TTY devices on the 2.6.xx kernel
* top can show CPU usage for IO-wait, IRQ, and softirq
* can set $PS_FORMAT to choose your own default ps format
* better width control (“ps -o pid,wchan:42,args”)
* width of ps PID column adjusts to your system
* vmstat lets you choose units you like: 1000, 1024, 1000000…
* top can sort by any column (old sort keys available too)
* top can select a single user to display
* top can be put in multi-window mode and/or color mode
* vmstat has the -s option, as found on UNIX and BSD systems
* vmstat has the -f option, as found on UNIX and BSD systems
* watch doesn’t eat the first blank line by mistake
* vmstat uses a fast O(1) algorithm on 2.5.xx kernels
* pmap command is SunOS-compatible
* vmstat shows IO-wait time
* pgrep and pkill can find the oldest matching process
* sysctl handles the Linux 2.5.xx VLAN interfaces
* ps has a new “-F” format (very nice, like DYNIX/ptx has)
* ps with proper BSD process selection
* better handling of very long uptimes
Comment by Anonymous — April 29, 2004 @ 5:48 PM
Re: procps 3 is at procps.sf.net
Hi Albert, nice to see you here, and hope you continue to read my journal. I was referring to http://tech9.net/rml/procps/, which is yet another fork of procps, but doesn’t seem as frequently updated as the one you pointed out.
Comment by ideawerkz — April 29, 2004 @ 6:27 PM