Disabling Hyperthreading in EC2 Cluster Compute instance:

#!/bin/bash
for cpunum in $(
cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list |
cut -s -d, -f2- | tr ',' '\n' | sort -un); do
echo 0 > /sys/devices/system/cpu/cpu$cpunum/online
done

https://forums.aws.amazon.com/message.jspa?messageID=189757

Malloc 4G limit problem:

Just discovered that you can malloc only up to 4G even when you're running on a 64-bit system. Try using mmap(MAP_ANON) for synthetic app. Not sure why this is so, need to dig into the kernel code. Later.

Linus Torvalds on Debuggers. (gdb) Epic! :)

http://lists.insecure.org/linux-kernel/2000/Sep/1177.html

Subject: Re: Availability of kdb
From: Linus Torvalds (torvalds@transmeta.com)
Date: Sep 06 2000

On Wed, 6 Sep 2000, Tigran Aivazian wrote:

> very nice monologue, thanks. It would be great to know Linus' opinion.
> I mean, I knew Linus' opinion of some years' ago but perhaps it
> changed? He is a living being and not some set of rules written in
> stone so perhaps current stability/highquality of kdb suggests to
> Linus that it may be (just maybe) acceptable into official tree?

I don't like debuggers. Never have, probably never will. I use gdb all the time, but I tend to use it not as a debugger, but as a disassembler on steroids that you can program.

None of the arguments for a kernel debugger has touched me in the least. And trust me, over the years I've heard quite a lot of them. In the end, they tend to boil down to basically:

It would be so much easier to do development, and we'd be able to add new things faster.

And quite frankly, I don't care. I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is
necessarily a good thing.

Apparently, if you follow the arguments, not having a kernel debugger leads to various maladies:

* you crash when something goes wrong, and you fsck, and it takes forever, and you get frustrated.
* people have given up on Linux kernel programming, because it's too hard and too time-consuming.
* it takes longer to create new features.

And nobody has explained to me why these are bad things.

To me, it's not a bug, it's a feature. Not only is it documented, but it's good, so it obviously cannot be a bug.

"Takes longer to create new features" - this one in particular is not a very strong argument for having a debugger. It's not as if lack of features or new code would be a problem for Linux, or, in fact, for the software industry as a whole. Quite the reverse. My biggest job is to say "no" to new features, not trying to find them.

Oh. And sure, when things crash and you fsck, and you didn't even get a clue about what went wrong, you get frustrated. Tough. There are two kinds of reactions to that: you start being careful, or you start whining about a kernel debugger.

Quite frankly, I'd rather weed out the people who don't start being careful early, rather than late. That sounds callous, and by God, it is callous. But it's not the kind of "if you can't stand the heat, get out the the kitchen" kind of remark that some people take it for. No, it's something much more deeper: I'd rather not work with people who aren't careful. It's Darwinism in software development.

It's a cold, callous argument that says that there are two kinds of people, and I'd rather not work with the second kind. Live with it.

I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work, if it just results in what I consider to be a better system.

And I'm not just saying that. I'm really not a very nice person. I can say "I don't care" with a straight face, and really mean it.

I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different level.

It's partly "source vs binary", but it's more than that. It's not that you have to look at the sources (of course you have to - and any good debugger will make that easy). It's that you have to look at the level above sources. At the meaning of things. Without a debugger, you basically have to go the next step: understand what the program does. Not just that particular line.

And quite frankly, for most of the real problems (as opposed to the stupid bugs - of which there are many, as the latest crap with "truncate()" has shown us) a debugger doesn't much help. And the real problems are what I worry about. The rest is just details. It will get fixed eventually.

I do realize that others disagree. And I'm not your Mom. You can use a kernel debugger if you want to, and I won't give you the cold shoulder because you have "sullied" yourself. But I'm not going to help you use one, and I would frankly prefer people not to use kernel debuggers that much. So I don't make it part of the standard distribution, and if the existing debuggers aren't very well known, I won't shed a tear over it.

Because I'm a bastard, and proud of it!

Linus

A simple timer (non-MPI)

struct timeval tempo1, tempo2;

long elapsed_utime; /* elapsed time in microseconds */

long elapsed_mtime; /* elapsed time in milliseconds */

long elapsed_seconds; /* diff between seconds counter */

long elapsed_useconds; /* diff between microseconds counter */

long total_usec = 0, total_msec = 0;

void StartSysTimer() {

gettimeofday(&tempo1, NULL);

}

void EndSysTimer() {

gettimeofday(&tempo2, NULL);

elapsed_seconds = tempo2.tv_sec - tempo1.tv_sec;

elapsed_useconds = tempo2.tv_usec - tempo1.tv_usec;

elapsed_utime = (elapsed_seconds) * 1000000 + elapsed_useconds;

elapsed_mtime = ((elapsed_seconds) * 1000 + elapsed_useconds/1000.0) + 0.5;

total_usec = total_usec + elapsed_utime;

total_msec = total_msec + elapsed_mtime;

}

void OutputTime() {

printf("Elapsed time = %ld microseconds\n", total_usec);

printf("Elapsed time = %ld milliseconds\n", total_msec);

}

Paper Abstract

- What is the problem?
- [Why is it important]?
- What is your solution?
- What is one going to find after reading your paper?

• What's the system about?
• Results

Flaky VMWare Server WebUI 2.0.2 workaround

VMWare Server 2.0.2 WebUI bug... this kind of reminds me of my EMC days!! similar infrastructure, unbelievably similar UI and interestingly, similar bugs too :-D

http://ip-forum.net/forum/index.php?topic=830.0;wap2

Common Errors in English Usage

http://www.wsu.edu/~brians/errors/errors.html#errors

An Interview With Edsger W. Dijkstra

http://cacm.acm.org/magazines/2010/8/96632-an-interview-with-edsger-w-dijkstra/fulltext

Add a system independent sleep/clock to your program

Add a system independent sleep/clock to your program

http://www.faqs.org/faqs/unix-faq/faq/part4/section-6.html

extern int        select();

     int
     usleep( usec )                            /* returns 0 if ok, else -1 */
           long                usec;           /* delay in microseconds */
           {
           static struct                       /* `timeval' */
                   {
                   long        tv_sec;         /* seconds */
                   long        tv_usec;        /* microsecs */
                   }   delay;          /* _select() timeout */

           delay.tv_sec = usec / 1000000L;
           delay.tv_usec = usec % 1000000L;

           return select( 0, (long *)0, (long *)0, (long *)0, &delay );
           }

Cool ways of adding numbers in a text file in bash:

awk '{s+=$0} END {print s}' /tmp/file.txt

paste -sd+ /tmp/file.txt | bc

Source: http://unstableme.blogspot.com/2009/11/sum-of-numbers-in-file-unix.html

Problem with Fortran + C code compilation:

undefined reference to `iargc_'
undefined reference to `getarg_'


Solution: use '_gfortran_iargc()' and '_gfortran_getarg_i4()' instead of 'iargc_()' and 'getargc_()'. This is specific to the situation where you link C with Fortran.
On the cluster, these are defined in /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgfortran.a.

http://osdir.com/ml/gcc.fortran/2005-02/msg00297.html
http://old.nabble.com/getarg-and-iargc-in-gcc-4.0.2-td1803996.html

Other links on Fortran + C compilation:

http://www.fnal.gov/docs/UNIX/unix_a.../uatf-107.html
http://astro.berkeley.edu/~wright/f2c.html
http://www.yolinux.com/TUTORIALS/Lin...rtranAndC.html