Kernel Traffic

Compression FS: NFS Jeff Garzik

Jeff Garzik suggested that, since any file could be made into a block device via loop, there might be no need to explicitly support the special case of swapfiles. He proposed ditching support for swapfiles in 2.5, and allowing the equivalent functionality to be done with loop.

Some folks suggested that loop was not stable enough to be counted on for swapping. Elsewhere, Eric W. Biederman discussed whether swapfile code was still necessary. He said:

Yes, and no. I'd say what we need to do is update rw_swap_page to use the address space functions directly. With block devices and files going through the page cache in 2.5 that should remove any special cases cleanly.

In 2.4 the swap code really hasn't been updated, the old code has only been patched enough to work on 2.4. This adds layers of work that we really don't need to be doing. Removing the extra redirection has the potential to give a small performance boost to swapping.

The case to watch out for are deadlocks doing things like using swapfiles on an NFS mount. As you point out we can already do this with the loop back devices so it isn't really a special case. The only new case I can see working are swapfiles with holes in them, or swapfiles that do automatic compression. I doubt those cases are significant improvements but it looks like they will fall out naturally.

Chris Wedgwood asked for confirmation that block devices would really be going through the page cache in 2.5, saying, I had hoped they would, that any block devices would just be page-cache views of underlying character devices, thus allowing us to remove the buffer-cache and the /dev/raw stuff.. Eric replied (admitting he could turn out to be wrong):

Block devices will go through the page cache in 2.5. It will take a while for the buffer cache to go away completely, but it is there for the code paths that haven't been updated. Buffer heads will stay.

The /dev/raw stuff is for those users that don't want to the kernel to cache their data and will continue to exist in some form.

FS: sysfs

Rolf Fokkens posted a short patch and said Some software (like procps) needs the HZ constant in the kernel. It's sometimes determined by counting jiffies during a second. The attached patch just "publishes" the HZ constant in /proc/sys/kernel/hz. Ulrich Drepper asked:

what is wrong with

getconf CLK_TCK

or programmatically

hz = sysconf (_SC_CLK_TCK);

Update your libc and this info will come from the kernel.

Rolf said that this didn't work -- it reads 100 while I changed it to 1024 in my kernel.

Andreas Jaeger said your kernel is broken, check AT_CLKTCK. Rolf concluded that for some architectures there actually _is_ a relationship between CLOCKS_PER_SEC and HZ, and for some there is _not_ [...] For i386 the relation apparently _is_ there. For IA64 there's the assumption however that that the relation is _not_ there, the kernel assumes that it's 100 HZ for ia32 _always_. Weird, and the thread ended somewhat inconclusively.

Kurt Garloff

Gianluca Anzolin reported trouble with 2.4.7-pre6aa1: e2fsck /dev/hda3 never finishes: I can't even stop the process with CTRL+C. Alt+SysRQ works and it tells me that the number of inactive dirty pages increases, while the active and free pages decrease. Andrea Arcangeli suggested that he back out the "40_blkdev-pagecache-5" patch. Andrea later explained more fully:

Ok, it was because I developed the blkdev-pagecache and 00_drop_async-io-get_bh-1 patches in two separated trees.

When both patches passed all the regression testing I merged both into 2.4.7pre6aa1 but unfortunately no reject reminded me I had to drop the get_bh from the async handler used by the blkdev pagecache (sorry!).

Andrea included a two-line patch. Kurt Garloff reported that he'd had the same problem, and that the patch fixed it for him. The thread ended there.

Wichert Akkerman John Levon Crutcher Dunnavant

Charles Samuels posted a URL to some docs he'd worked up, to provide API descriptions of various kernel functions. He asked for help including information on all exported functions. Ignacio Vazquez-Abrams suggested using DocBook instead of plain XML, but Charles replied, DocBook is more "bookish" complete with chapters and all. I've used it before, it's nice, but not for this, in my opinion. Also, the backend just moves the XML data into a temporary MySQL database for easy searching, and sorting, and something like that, I think, would be much more difficult with docbook. Wichert Akkerman pointed out that DocBook could be XML, but there was no reply.

Elsewhere, Crutcher Dunnavant pointed out that there was already a project underway to document the kernel APIs. He also announced his own documentation effort to cover best practices for kernel hacking. He added that help would be welcome, and that folks should be aware the document was in the very early stages. John Levon also gave a link to the existing API doc.

David Balazic, running 2.4.6-ac5 on an AMD Duron 700, reported that /proc/cpuinfo reported a 64K cache size, when he knew the Duron had 192K of cache: 64 L1 I, 64 L1 D, 64 L2 unified.

Christian Borntræger said As far as I know older Durons have a bug. They report a wrong size for the cache. But David pointed out that The kernel messages at boot have no trouble finding out the correct cache info. Elsewhere, Christian surmised that only the second level cache size was being reported in /proc/cpuinfo. David replied that it should say "L2 cache size:" It is a bug in any case. The body of the subthread ended there.

Elsewhere, there was a debate over the proper abbreviation for `kilobytes'. Ketil Froyn suggested looking at acronymfinder.com, saying that the proper abbreviations were 'K' for 1024, 'k' for 1000 and 'B' for bytes and 'b' for bits. At one point, David Woodhouse said, The correct prefix to signify a multiple of 1024 is 'Ki', and posted a patch to make the change. A couple of posts later, Alan Shutko opined that 'Ki' was a reasonably new standard that hasn't caught on, because many people think that "kibibyte" is stupid.