Slashdot Mirror

← Back to Stories (view on slashdot.org)

Interview With Linux Kernel Guru Ingo Molnar

Posted by timothy on from the tux-is-interesting dept.

An anonymous reader writes "KernelTrap has posted an interview with Ingo Molnar, the Linux kernel guru who wrote the O(1) scheduler and improved threading enough to allow hundreds of thousands of threads to run in parallel. The interview covers a wide range of interesting topics, offering much insight into the latest and greatest improvements found in the Linux development kernel. From the new rmap VM, to BitKeeper, to TUX, to comparing Linux with FreeBSD, it's all there..."

4 of 22 comments (clear)

  1. Re:Description of O(1) scheduler? by iluvitar · · Score: 2, Informative

    I think he intended for the question to be "how does the O(1) work?", and not "what's O(1)?". The article mentionned the two priority queues but nothing more.

    There's a nice description about how it works here:
    http://www.uwsg.iu.edu/hypermail/linux/kernel/0201 .0/0810.html
    Just scroll down to the "Design" section (quarter of the way down the page).

  2. Re:Description of O(1) scheduler? by sesquiped · · Score: 4, Informative

    http://www.cs.brown.edu/courses/cs167/lectures/13l inux.pdf
    pages 7-20

  3. Re:The numbers thingy by Anonymous Coward · · Score: 1, Informative

    In Linux/Unix/BSD, why do people sometimes put numbers after programs? ie. rm(1)?

    That's the manual section that they're in. Can't remember off the top of my head but it's roughly 1 is command line utils, 2 and 3 are API and runtime library, 5 for configuration files, 8 for admin utils/daemons, etc.

    Sometimes there are entries in different sections with the same name - to find the one you want you have to specify the manual section on the 'man' command line. mkdir(1), for example, is a command line utility and mkdir(2) is a system call.

    Note that this isn't the same as O(1) which is an upper bound on how an algorithm scales - see Zapman's (redundant) post above.

  4. Re: slight exageration? not. by Ingo+Molnar · · Score: 5, Informative
    The test i did really involved the creation of 100,000 parallel threads, for a second or so. Obviously they did not do much work, other than go to sleep, but the runqueue length was definitely 100,000.


    The test would be meaningless otherwise - you can create/destroy 100,000 threads in a row on any OS without any problem.


    Furthermore, Anton Blanchard tested _1 million_ parallel threads on one of his big PowerPC boxen, using the new threading code - the test completed in roughly 30 seconds and he has got an insane load-average in the hundreds of thousands range - a further proof that the threads were running in parallel.