These days, the init.d script dependencies in Squeeze are quite complete, so complete that it is actually possible to run all the init.d scripts in parallell based on these dependencies. If you want to test your Squeeze system, make sure dependency based boot sequencing is enabled, and add this line to /etc/default/rcS:

CONCURRENCY=makefile

That is it. It will cause sysv-rc to use the startpar tool to run scripts in parallel using the dependency information stored in
/etc/init.d/.depend.boot, /etc/init.d/.depend.start and /etc/init.d/.depend.stop to order the scripts. Startpar is configured to try to start the kdm and gdm scripts as early as possible, and will start the facilities required by kdm or gdm as early as possible to make this happen.

Give it a try, and see if you like the result. If some services fail to start properly, it is most likely because they have incomplete
init.d script dependencies in their startup script (or some of their dependent scripts have incomplete dependencies). Report bugs and get the package maintainers to fix it. :)

Running scripts in parallel could be the default in Debian when we manage to get the init.d script dependencies complete and correct. I expect we will get there in Squeeze+1, if we get manage to test and fix the remaining issues.

If you report any problems with dependencies in init.d scripts to the BTS, please usertag the report to get it to show up at
<URL: http://bugs.debian.org/cgi-bin/pkgr…s-ng-devel@lists.alioth.debian.org >.

Happy hacking,
Petter Reinholdtsen

PAE really really sucks.

The biggest single reason to go 64-bit is exactly because of physical address space. Your virtual address space needs to bea multiple of the physical one: when you hit 1GB of RAM, 32-bit virtual memory is no longer acceptable. You literally do need more virtual memory than physical.

PAE turned that very simple fact on its head, and screwed things up royally. Whoever came up with the idea was totally incompetent, and had forgotten all the DOS HIGHMEM pains. There’s a damn good reason why we left the 286 behind, and started using 386′s, instead of having HIGHMEM crap with windows into a bigger physical space.

Repeat after me:

Virtual space needs to be bigger than physical space. Not “as big”. Not “smaller”. It needs to be bigger, by a factor of at least two, and that’s quite frankly pushing it, and you’re much better off having a factor of ten or more.

Anybody who doesn’t get that is a moron. End of discussion.

Reasons for why you need a bigger virtual space:

• you need to map that physical memory somehow, and no, tiny windows into the physical memory simply do not cut it! If you cannot have normal pointers to the physical space, it immediately means that you need to jump through serious hoops to get there.
• you additionally need to be able to remap things in alternate ways (ie user space) or make space for non-memory issues (virtual page tables, IO, you name it)

Ergo, a factor-of-two is a requirement. PAE was a total and utter disaster.

Yes, Linux supported it, and probably did so better than anybody else. But “better than anybody else” still wasn’t very good. Because you couldn’t use normal pointers to point to arbitrary physical memory, all the memory that couldn’t be accessed directly (ie anythign that didn’t fit in the virtual address map, which also had the user space memory in it) was basically limited to “special uses only”.

So you could allocate user pages in it, but you had huge problems with things like internal kernel data structures, which can be the bulk of your memory needs under some (not that unusual) loads. Directory caches, inodes, etc couldn’t use it, and in general it meant that under Linux, if you had more than 4GB of physical memory, you generally ran into problems (since only 25% of memory was available for normal kernel stuff – the rest had to be addressed through small holes in the tiny virtual address space).

I’m not at all surprised that Windows didn’t push PAE either. It was a total braindamage. I bet they supported it in the server offerings just because they had to, and I bet they did a much worse job of it than Linux did, and the reason you can do that with servers is that the loads are much easier, and you can expect maintainers to set magic config entries to tweak it to make it appear to work well for any particular load, when in reality it is fragile as hell and works only with duct-tape and prayers.

That kind of “duct-tape and prayers and lots of specialized knowledge about the load” is simply not possible in a desktop environment. Yeah, users have prayers, but they lack the duct-tape and the knowledge to work around the problems.

And dammit, in this age and date when almost everybody has a gigabyte of RAM in any new machine, anybody who still thinks that “not that many people need 64-bits” is simply not aware of what he’s speaking of.

Go back and play with HIGHMEM.SYS on a 286, and stop blathering crap. When you’ve spent the last ten years of your life working with HIGHMEM.SYS, then you can come back and tell me that we still don’t need 64 bits. Until that is the case, anybody who still doesn’t get why 64 bits is a requirement should just shut up rather than make a total fool of himself.

So repeat after me: PAE didn’t ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software.

So no, PAE does not mean that you can use more than 4GB of RAM. Even before PAE, the practical limit was around 1GB, and PAE didn’t move that post a fraction of an inch!

Linus

It was recently noted that ioctl() system calls are still executed with the Big Kernel Lock (BKL) held. A suggestion was made that drivers which can implement ioctl() without the BKL held should be specially flagged as a way of increasing parallelism. That suggestion looks like it will not get very far. But it did pique your editor’s interest in current use of the BKL. Besides, there hasn’t been a whole lot else going on this week.

The BKL is an artifact from when the Linux kernel first supported multiprocessor systems. Making the kernel safe for concurrent access from multiple CPUs has been a multi-year task; it is not a job that could have been done all at once at the beginning. So Linux 2.0 supported SMP systems by way of the BKL, which only allowed one processor to be running kernel code at any given time. The BKL is essentially a spinlock, but with a couple of interesting properties:

• The BKL can be taken recursively; the kernel remembers how many times a given thread has called lock_kernel() and does the right thing. Normal spinlocks are rather less forgiving.
• Code holding the BKL can sleep. The lock is released while the given thread sleeps, and reacquired upon awakening.

The BKL made SMP Linux possible, but it didn’t scale very well. Its overhead could be felt even with two processors, and it made running on anything larger problematic. So the kernel developers have been breaking the BKL into finer-grained locks ever since. Thus, for example, the block I/O subsystem went from the BKL to its own lock (io_request_lock) in 2.2, and from that to individual queue locks in 2.6. The kernel now has thousands of locks, and some people had assumed that the BKL would be gone by 2.6.

As it turns out, there are still over 500 lock_kernel() calls in the 2.6.6 kernel. For the curious, here are some of the places which still rely on this old, system-wide lock:

• The core kernel retains a few calls. The implementation of the reboot() system call is one of them; this is, of course, not one of the more performance-sensitive parts of the kernel. The boot-time early initialization process is also run with the BKL held. The sysctl() system call is run under the BKL; interestingly, while much of /proc is also implemented under the BKL, it appears that reads and writes to /proc/sys do not run with the BKL held.
• Many older filesystems (UFS, coda, HPFS, FAT, NCP, SMB, Minix, etc.) make heavy use of the BKL for serialization. The UnixWare “Boot File System” implementation has several calls; somehow, they seem unlikely to be fixed anytime soon. There are also lock_kernel() calls in NFS, UDF, isofs, the reiserfs journaling code, autofs, and some others. The ext2 filesystem uses the BKL to protect modifications to the superblock; ext3, instead, had all of its lock_kernel() calls purged during the 2.5 development process.
• The rpciod kernel thread spends its entire life with the BKL held.
• Core dumps are created with the BKL held.
• Block and character devices have their open() methods called under the BKL. Block release() methods are also called this way, but that is not true for char drivers. The default llseek() method runs under the BKL, but, if a driver or filesystem provides its own llseek() method, that method will not be called with the BKL held. The fasync() method is always called under the BKL. As noted at the beginning, ioctl() methods are called with the lock held; additionally, the ugly code which does 32-bit emulation on 64-bit systems needs the BKL.
• The file locking code still requires the BKL.
• Almost 10% of the lock_kernel() calls can be found in the (old, deprecated) OSS sound code. The ALSA code has no BKL calls, with one exception: the implementation of its /proc files.
• Most of the architectures retain some calls in the arch-specific code. The ptrace() system call is one common place for these calls. i386 also uses the BKL to protect llseek() calls on the CPUID and MSR pseudo-devices. uClinux performs execve() calls under the BKL.
• Almost all of the remaining BKL calls are to be found in device drivers. The TTY subsystem still has quite a few of them, as does USB. Many of these calls are protecting llseek() implementations. Quite a few of the rest are for the creation of special-purpose kernel threads: the daemonize() function needs to be called with the BKL held. Those calls can, presumably, go away as the driver code is (slowly) migrated over to the new kthread calls.

Given how poorly the BKL is viewed, it may be surprising that so many places in the kernel still use it. The simple fact is that, with regard to the BKL, all of the low-hanging fruit has long since been taken. For most of the remaining calls, removing the BKL is not worth the trouble and code churn. So, while removal of the remaining calls over the 2.7 development series looks entirely possible, it would not be surprising if that does not happen.

http://lwn.net/Articles/86859/

/*
* It would make sense to put struct rusage in the task_struct,
* except that would make the task_struct be *really big*.  After
* task_struct gets moved into malloc’ed memory, it would
* make sense to do this.  It will make moving the rest of the information
* a lot simpler!  (Which we’re not doing right now because we’re not
* measuring them yet).
*
* When sampling multiple threads for RUSAGE_SELF, under SMP we might have
* races with threads incrementing their own counters.  But since word
* reads are atomic, we either get new values or old values and we don’t
* care which for the sums.  We always take the siglock to protect reading
* the c* fields from p->signal from races with exit.c updating those
* fields when reaping, so a sample either gets all the additions of a
* given child after it’s reaped, or none so this sample is before reaping.
*
* Locking:
* We need to take the siglock for CHILDEREN, SELF and BOTH
* for  the cases current multithreaded, non-current single threaded
* non-current multithreaded.  Thread traversal is now safe with
* the siglock held.
* Strictly speaking, we donot need to take the siglock if we are current and
* single threaded,  as no one else can take our signal_struct away, no one
* else can  reap the  children to update signal->c* counters, and no one else
* can race with the signal-> fields. If we do not take any lock, the
* signal-> fields could be read out of order while another thread was just
* exiting. So we should  place a read memory barrier when we avoid the lock.
* On the writer side,  write memory barrier is implied in  __exit_signal
* as __exit_signal releases  the siglock spinlock after updating the signal->
* fields. But we don’t do this yet to keep things simple.
*
*/