Kernel Traffic #267 by Zack Brown
[email protected] Sun, 18 Jul 2004 13:18:09 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #267 For 18 Jul
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 9 Jun - 23 Jun (33 High-Res Timer (HRT) Support For 2.6; Some
posts) Debate Over Alternatives
2. 15 Jun - 22 Jun (12 Support For RSA Crypto API In 2.6
posts)
3. 15 Jun - 19 Jun (40 Linux 2.6.7 Released; ESSID Bug Introduced;
posts) SiS900 Full-Duplex Fix Not Applied
4. 16 Jun - 17 Jun (5 Generic SCSI Build Target With Target Drivers
posts)
5. 16 Jun - 17 Jun (11 Linux 2.4.27-pre6 Released
posts)
6. 17 Jun - 21 Jun (7 Status Of Moxa Serial Card Support Under SMP
posts)
7. 18 Jun - 19 Jun (8 Input Patches; serio SysFS Integration
posts)
8. 18 Jun (1 USB Updates; New Host Controller Driver For
post) lh7a404 Deavices
9. 19 Jun - 20 Jun (3 Linux 2.4.27-rc1
posts)
10. 20 Jun - 22 Jun (23 Linux 2.6.7-mm1 Released
posts)
11. 21 Jun (1 Videotext Driver Comment For SAA5246A Decoder
post) Support
12. 21 Jun - 23 Jun (5 Status Of linux/802_11.h, Used By Some 3rd
posts) Party Drivers
13. 23 Jun (4 Precise CPU Accounting Patch Ported From 2.4
posts) To 2.6.7
14. 23 Jun - 24 Jun (7 Status Of Preemption/Low-Latency In 2.6.7
posts)
15. 23 Jun - 24 Jun (17 Policy For Using GCC Built-Ins
posts)
16. 24 Jun (1 Enhanced Linux System Accounting (ELSA)
post) Updated For Linux 2.6.7
Mailing List Stats For This Week
We looked at 2195 posts in 12920K.
There were 555 different contributors. 287 posted more than once. 173 posted
last week too.
The top posters of the week were:
* 84 posts in 512K by Greg KH
* 55 posts in 234K by Andrew Morton
* 53 posts in 250K by William Lee Irwin III
* 53 posts in 242K by Jeff Garzik
* 48 posts in 252K by Sam Ravnborg
* Full Stats
1. High-Res Timer (HRT) Support For 2.6; Some Debate Over Alternatives
9 Jun - 23 Jun (33 posts) Archive Link: "[ANNOUNCE] high-res-timers patches
for 2.6.6"
Topics: Microkernels: Adeos, POSIX, Real-Time: RTAI, Real-Time: RTLinux
People: Geoff Levand, William Lee Irwin III, George Anzinger, Arjan van de Ven
, Karim Yaghmour
Geoff Levand said:
Available at http://tree.celinuxforum.org/pubwiki/moin.cgi/
CELinux_5fPatchArchive
For those interested, the set of three patches provide POSIX high-res timer
support for linux-2.6.6. The core and i386 patches are updates of George
Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge <http://
sourceforge.net/projects/high-res-timers/>. The ppc32 port is not available
on SourceForge yet.
William Lee Irwin III said he'd been under the impression that George
Anzinger's patches had already been merged into the 2.6 kernel. He added, "At
the very least there's already a kernel/posix-timers.c" . Someone else, in
reply to this, said that the POSIX interface of the timers was what had
actually been merged. The patches to obtain resolution on the order of 10
microseconds, the person said, had not been merged into the official 2.6 tree.
William replied, "That sounds useful. Any chance you could post them to lkml
for review? They're significantly less likely to actually be looked at and/or
included if ppl have to chase URL's."
Elsewhere, Arjan van de Ven complained about the large number of #ifdefs in the
patch. He suggested that if the code were made non-optional, but just a core
kernel feature, a lot of this could be cleaned up. George Anzinger replied,
"this would break all the archs that don't have the needed arch dependent code
yet. By making the high-res part depend on the arch config turning on a config,
we don't break the archs and they can sign up as they get their act together."
Arjan said, "if the price is this amount of uglyness then that's the wrong
approach imo. Would be nicer to make dummy helpers the arch people can just
take during the transition instead." George came back with, "I have another
solution, connected with the ability to turn it off at boot time. Unsupporting
archs would just not define a flag." At this point various folks descended into
technical issues.
Elsewhere, Karim Yaghmour said:
Just reading from the Posix 1003.1b section 14 spec referenced by the HRT
main project page, I see the following:
Realtime applications must be able to operate on data within strict
timing constraints in order to schedule application or system events.
Timing requirements can be in response to the need for either high
system throughput or fast response time. Applications requiring high
throughput may process large amounts of data and use a continuous
stream of data points equally spaced in time. For example,
electrocardiogram research uses a continuous stream of data for
qualitative and quantitative analysis.
If this is really the goal here, then why not just integrate Adeos into the
kernel and make some form of HRT as a loadable module that uses Adeos to
provide its services?
Currently Adeos runs on x86, ARM (MMU-full and MMU-less), PPC, so
portability is not an issue. Plus, the interface provided can either be
directly used by drivers to get hard-rt interrupts or it can be used by
another layer to provide more elaborate services (like RTAI or,
potentially, HRT.) Using the virtual interrupts that can be dynamically
allocated at runtime, it's rather easy to send signals between domains.
Sure, you may not have the exact Posix 1003.1b API, but I don't remember
there being any persistent goal of having the kernel conform to any
standard.
George replied, "I don't see how this delivers any added value to the user. I
suppose code running at the kernel level might gain something, but at the user
level we still have to deal with preemption latencies, which are the biggest
problem (and, aside from messing up the accuracy of the timers, are NOT timer
issues at all)." Karim said:
Actually I think the point I'm trying to make can't be fairly conveyed
without providing a lot of background of what can be done with Adeos. I
would suggest that those interested do some digging. Among other things,
you may want to read about RTAI/fusion:
http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/rtai-fusion.html
http://www.fdn.fr/~brouchou/rtai/modules.php?name=Content&pa=showpage&pid=1
George replied:
I think the real problem is an open source question. The RTAI and RTLINUX
folks are not exactly in the same camp (either with each other OR with
LINUX) in this regard. Should that change and one or more of these become
truly open source without others claiming "foul", there are vendors who are
ready and willing to work with the code. Vendors of open source (and their
customers) don't want to find themselves in law suits...
As such, this is really off topic... as is a discussion of the merits of
this sort of solution. On this list we are interested in working in the
confines of LINUX as found on linux.org possibly modified by truly open
source patches and packages.
Karim said that George's was an ignorant view, and said, "RTAI has always been
and will always been "open source". I'm not going to qualify other peoples'
claims against it, but let me just say that you've succumbed to FUD" . There
was no further discussion on that point, however.
2. Support For RSA Crypto API In 2.6
15 Jun - 22 Jun (12 posts) Archive Link: "RSA"
People: Joy Latten, Kristian S?rensen, Serge E. Hallyn, Tom St. Denis, James
Morris
Joy Latten asked, "Is anyone working on implementing RSA encryption/decryption
into the kernel's cryptoapi? If not, I was considering starting such a
project." Kartikey Bhatt said he'd like to contribute to such a project; and he
and Joy took that discussion to private email. Kristian S?rensen also said to
Joy:
The Umbrella project (umbrella.sf.net (http://umbrella.sf.net) ) also needs
the ability to use public key cryptography within the Linux kernel (though
only to verify signatures).
We were planing to implement RSA or ElGamal (porting some of GPG) to the
kernel for that purpose. However, if this project gets started, we will be
very interested. In the automn we might also have some development hours to
contribute with :-)
Elsewhere, James Morris asked if Joy, Serge E. Hallyn and the other folks on
the project were trying to create a generic asymmetric cryptographic API; Serge
replied:
Is a separate generic assymetric crypto API really necessary?
The cryptoapi usage model is to do a setkey before any encrypt or decrypt.
The setkey will be done with either a public or private key. So there is no
need to have a public_key_alg with separate public_encrypt and
private_encrypt functions, as this distinction is implied at the setkey
time. So our plan was to just add another crypto_alg for rsa_1024.
If anyone can point out why this is insufficient, then we will certainly
reconsider.
Tom St. Denis replied:
In essence for a digsig module you'll require the ability to
1. import a PK key [from a binary packet or a cert, preferably the
former].
2. free a PK key from memory (no need to waste dynamic resources like
bignums while not being used).
3. ability to sign/verify/encrypt/decrypt which amounts to a exptmod and
PKCS #1 [v2.0 preferably] padding.
An API exactly mirroring the symmetric side won't really work 100%. For
instance, symmetric operations are not likely to fail [I don't know how
error handling is performed]. Also decrypt/verify ops may fail hard [due to
lack of heap] or soft [invalid packet].
It would probably make more sense to design a simple API for PK crypto [say
support RSA/ECC/DH/DSA ;-)] then to mash the symmetric crypto API into
something compatible.
On a side note I've been contacted about my interest in making this happen
[hence my reply here]. I'm offering my public domain LibTomCrypt [and
indirectly LibTomMath] for the task. Currently I'm working on reducing the
stack usage in LibTomCrypt's PK operations.
What I propose is we can port LibTomCrypt's [by stripping out stuff that
isn't required like symmetric crypto] PK code to a kernel module to be
released under the GPL. Since the code is already public domain [and I
personally wrote all of the relevent code myself == no copyright issues]
there shouldn't be any problems with this.
He and Serge went back and forth on the technical issues, and them possibly
took the conversation off-list. Serge was thrilled with Tom's contributions,
and especially with the availability of Tom's code.
3. Linux 2.6.7 Released; ESSID Bug Introduced; SiS900 Full-Duplex Fix Not
Applied
15 Jun - 19 Jun (40 posts) Archive Link: "Linux 2.6.7"
Topics: Kernel Release Announcement, Networking
People: Linus Torvalds, Tomas Szepe, Alexander Viro, Dominik Karall, Jeff
Garzik
Linus Torvalds announced Linux 2.6.7, saying, "The most notable change may be
the one-liner that should fix the embarrassing FP exception problem. Other than
that, we've had a random collection of fixes and updates since rc3. cifs, ntfs,
cpufreq. ide, sparc, s390." Tomas Szepe replied:
2.6.7's airo.ko (unlike 2.6.6's) won't allow the user to set ESSID via
"echo myessid >/proc/driver/aironet/ethX/SSID".
Changes like this shouldn't probably be made in the middle of a stable
series.
Alexander Viro replied with a short patch, saying, "Changes like this are
called bugs. The thing is, original variant of function (actually, both read
and write) was also buggy and trivially exploitable, so fixing it was needed.
Fscking it up was not, obviously." Tomas tried Alexander's fix, and confirmed
that it worked.
Elsewhere, Dominik Karall asked, "Is there any reason why the
sis900-fix-phy-transceiver-detection.patch wasn't moved to the stable tree?
It's a now for a long time in -mm patches and without that patch, a lot of
sis900 cards does not work in full-duplex 100Tx-FD mode." Jeff Garzik replied,
"It still needs work, as the updated driver appears to scan the first phy
incorrectly, which IMO would break _other_ situations that are presently
working. I'll try to get to it in the next couple days; the short answer is to
look at other PCI ethernet drivers and note how they scan MII."
4. Generic SCSI Build Target With Target Drivers
16 Jun - 17 Jun (5 posts) Archive Link: "[ANNOUNCE] Generic SCSI Target
Middle Level for Linux (SCST) with target drivers"
Topics: Disks: SCSI, SMP
People: Vladislav Bolkhovitin, Matthew Wilcox, Christoph Hellwig
Vladislav Bolkhovitin said:
I would like to announce the first public release of a generic SCSI target
middle level subsystem for Linux (SCST) with Qlogic 2200/2300 target driver
and a patch for for UNH-iSCSI Target 1.5.3 to work over SCST.
SCST is designed to provide unified, consistent interface between SCSI
target drivers and Linux kernel and simplify target drivers development as
much as possible. It has the following features:
+ Very low overhead, fine-grained locks and simplest commands processing
path, which allow to reach maximum possible performance and scalability
that close to theoretical limit.
+ Incoming requests can be processed in the caller's context or in one of
the internal SCST's tasklets, therefore no extra context switches
required.
+ Complete SMP support.
+ Undertakes most problems, related to execution contexts, thus
practically eliminating one of the most complicated problem in the
kernel drivers development. For example, a target driver for Qlogic
2200/2300 cards, which has all necessary features, is about 2000 lines
of code long, that is at least in several times less, than the
initiator one.
+ Performs all required pre- and post- processing of incoming requests
and all necessary error recovery functionality.
+ Emulates necessary functionality of SCSI host adapter, because from a
remote initiator's point of view SCST acts as a SCSI host with its own
devices. Some of the emulated functions are the following:
o Generation of necessary UNIT ATTENTIONs, their storage and delivery
to all connected remote initiators (sessions).
o RESERVE/RELEASE functionality.
o CA/ACA conditions.
o All types of RESETs and other task management functions.
o REPORT LUNS command as well as SCSI address space management in
order to have consistent address space on all remote initiators,
since local SCSI devices could not know about each other to report
via REPORT LUNS command. Additionally, SCST responds with error on
all commands to non-existing devices and provides access control
(not implemented yet), so different remote initiators could see
different set of devices.
o Other necessary functionality (task attributes, etc.) as specified
in SAM-2, SPC-2, SAM-3, SPC-3 and other SCSI standards.
+ Device handlers architecture provides extra reliability and security
via verifying all incoming requests and allows to make any additional
requests processing, which is completely independent from target
drivers, for example, device dependent exceptional conditions treatment
or data caching.
Interoperability between SCST and local SCSI initiators (like sd, st) is
the additional issue that SCST is going to address (it is not implemented
yet). It is necessary, because local SCSI initiators can change the state
of the device, for example RESERVE the device, or some of its parameters
and that would be done behind SCST, which could lead to various problems.
Thus, RESERVE/RELEASE commands, locally generated UNIT ATTENTIONs, etc.
should be intercepted and processed as if local SCSI initiators act as
remote SCSI initiators connected to SCST.
Interface between SCST and target drivers is based on work, done by
InterOperability Lab (IOL) of University of New Hampshier (UNH).
In addition, the project contains a target driver for Qlogic 2200/2300
Fibre Channel cards and a patch for for UNH-iSCSI Target 1.5.3 that makes
it work over SCST.
In the current version 0.9.1 SCST looks to be quite stable (for beta) and
useful. The same is for Qlogic 2200/2300 target driver. Only 2.4 kernels
currently supported, but update for 2.6 is coming soon. No kernel patches
are necessary. Tested on i386 only, but should work on any other supported
by Linux platform.
More information, including the source code and detail documentation, could
be found on http://scst.sf.net.
Matthew Wilcox asked, "Why does this need to be done in kernel space? My
impression was that an iSCSI target would best be done in userspace." But
Vladislav replied:
There is not only iSCSI target (i.e. software one) in the world. For
hardware targets if you were switch on each command (IRQ) to user space and
back, it would be huge performance penalty, especially for commands that
request small data transfers. Take a look on the Qlogic target: all job is
done in the tasklet, without ever context switch. The same is for upcoming
iSCSI hardware, like Qlogic QLA4010, which also supports target mode.
BTW, the processing is simple enough, the main SCST module is only about
60Kb long. The main point is that this processing must be done in _each_
SCSI target driver. So, consider SCSI target mid-level like a library
(framework) for such drivers, exectly as the regular SCSI mid-level for
regular SCSI drivers.
Christoph Hellwig also remarked, "The code looks pretty neat to me, there's a
few issues I'd like to see addresses but that doesn't make sense before the 2.4
support is dropped and there's an actual LLDD for 2.6. But I think for most
interesting scenarios in the storage virtualization world your driver is pretty
much useless because it wants to dispatch directly to a scsi device and doesn't
go through the block layer. So no fancy volume managers/etc there to make
interesting storage virtualization boxes." To which Vladislav replied:
For that is intended upcoming block device handler with block layer/cache
support, which will be in its exec() method check, if requested blocks in
cache, and, if not, dispatch the commands to block layer, leaving regular
scsi_do_req() calls for tapes, changers, etc. In the similar way "_perf"
handlers work (they don't send READ/WRITE commands to SCSI devices for
performance studies).
This device handler is on our todo list. Actually, it's quite simple and if
anyone interested, he's help would be greatly appreciated.
5. Linux 2.4.27-pre6 Released
16 Jun - 17 Jun (11 posts) Archive Link: "Linux 2.4.27-pre6"
Topics: FS: JFS, USB
People: Marcelo Tosatti, Andreas Haumer
Marcelo Tosatti announced Linux 2.4.27-pre6, saying:
It contains a significant amount of USB fixes, JFS update, netfilter/sctp
fixes, CDROM driver update, tg3 update, SPARC/Alpha fixes.
And more importantly the FPU x86/x86-64 crash fix.
Andreas Haumer reported that 'make xconfig', broken also in -pre5, was still
broken. He posted a patch to fix it.
6. Status Of Moxa Serial Card Support Under SMP
17 Jun - 21 Jun (7 posts) Archive Link: "Use of Moxa serial card with SMP
kernels"
Topics: SMP
People: Bruce Marshall, Randy Dunlap, Stephen Lin, Jan-Benedict Glaw
Bruce Marshall wanted to use a Moxa serial card on his SMP system, but had been
told "back when 2.6.4 was new that the selection of a Moxa serial card was not
possible if an SMP kernel was selected." He asked if the situation had
improved, as he was anxious to reenable SMP on his system. Jan-Benedict Glaw
and Randy Dunlap confirmed that the problem had not been fixed, and that no one
was currently working on it. Randy said:
Both Moxa serial drivers (moxa & mxser) are BROKEN_ON_SMP because they use
cli() to disable interrupts for critical sections. See Documentation/
cli-sti-removal.txt for details. They will need some acceptable modern form
of protection there,
Is anyone working on this? not that I've heard of. Have you tried this
email address: [email protected]
Bruce tried that address, and after a couple of private exchanges, received
this reply from Stephen Lin, a Moxa tech support fellow: "I've got updated news
from the R&D Div., they are testing the latest beta version of the driver for
all the Moxa cards, only they can not provide me with a precise schedule. Your
case will be remaining open until it is resolved, I will also keep you update
with the information."
7. Input Patches; serio SysFS Integration
18 Jun - 19 Jun (8 posts) Archive Link: "[PATCH 0/11] New set of input
patches"
Topics: FS: sysfs
People: Dmitry Torokhov, Vojtech Pavlik, Jan-Benedict Glaw, Jan-Benedict, Linus
Torvalds
Dmitry Torokhov said, "Here is my new set of input patches, most important IMHO
is serio sysfs integration. It is not complete in sense that we need add
attributes to individual drivers (like rate and resolution and protocol to
psmouse) and create some platform devices for i8042, q40kbd, etc so serio ports
would have parents. But the core integration is done. Unfortunately I do not
have 90% hardware to test my changes so there could be some problems, although
I tried to compile everything I could. The patches are against Vojtech's tree
and should apply to -mm as well." Jan-Benedict Glaw complained that, as the
patches were created against Vojtech Pavlik's tree, they would not apply to
Linus Torvalds' version; making them harder to work with. Dmitry replied, "I do
not consider it tested enough to be ready for Linus yet :) I am thinking about
publushing my input-sysfs bk tree... Will there be an interest in it or you
just want a patch against the vanilla 2.6.7? I can do a wholesale patch but
splitting my changes from other stuff in Vojtech's tree does not sound very
appealing..." Jan-Benedict said that he'd really prefer a patch against the
Linus tree, but that he could try working on Vojtech's tree for the purposes of
this patch.
8. USB Updates; New Host Controller Driver For lh7a404 Deavices
18 Jun (1 post) Archive Link: "[BK PATCH] USB patches for 2.6.7"
Topics: USB
People: Greg KH
Greg KH said:
Here are a number of various USB fixes and cleanups for 2.6.7. All of these
patches have been in the past few -mm releases.
There's lots of good stuff in here:
+ gadget fixes
+ new host controller driver for lh7a404 devices
+ lots of hub locking rework to fix up the mess there.
+ sparse markups to remove warnings
+ loads of bugfixes.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/usb-2.6
Patches will be posted to linux-usb-devel as a follow-up thread for those
who want to see them.
9. Linux 2.4.27-rc1
19 Jun - 20 Jun (3 posts) Archive Link: "Linux 2.4.27-rc1"
Topics: Power Management: ACPI, USB
People: Marcelo Tosatti, Geert Uytterhoeven
Marcelo Tosatti announced Linux 2.4.27-rc1, saying, "It contains a handful of
ACPI bugfixes, HPFS update, USB fixes, amongst other smaller fixes." Geert
Uytterhoeven found some compile-time warnings that were introduced by this
patch, and posted another to get rid of them; which Marcelo accepted.
10. Linux 2.6.7-mm1 Released
20 Jun - 22 Jun (23 posts) Archive Link: "2.6.7-mm1"
Topics: Kernel Release Announcement
People: Andrew Morton
Andrew Morton announced Linux 2.6.7-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/
2.6.7-mm1/
+ Added a new vm tunable: /proc/sys/vm/vfs-cache-pressure.
This allows tuning of the kernel's preference for reclaiming VFS caches
versus pagecache.
vfs-cache-pressure=0: dentry and inode caches aren't reclaimed at all
vfs-cache-pressure=100: default - current behaviour
vfs-cache-pressure > 100: reclaim the VFS caches harder.
It seems that large values of vfs-cache-pressure are needed to make
much difference: 1000 or more.
+ Under some circumstances the current page reclaim code can hold
interrupts off for a long time. That is fixed here.
+ I went through and dropped a bunch of patches which don't seem to be
very useful now - mainly debug stuff.
+ Various driver updates and random fixes
11. Videotext Driver Comment For SAA5246A Decoder Support
21 Jun (1 post) Archive Link: "[PATCH][2.6][V4L] saa5246a Videotext driver
update"
People: Michael Geng
Michael Geng said:
I uploaded an update to the Videotext driver for the SAA5246A videotext
decoder in
http://www.michaelgeng.de/linux/saa5246a-2.6.7.patch
The update only changes comments showing that the driver also works for the
SAA5281 videotext decoder chip. This is not surprising because according to
the data sheet of the SAA5281 it is compatible to the SAA5246A. I have
tested this with a Siemens Multimedia Extension Board (MXB).
I also added MODULE_AUTHOR and MODULE_DESCRIPTION macros which were missing
up to now.
Patch comment:
V4L: saa5246a driver update, supports saa5281
Signed-off-by: Michael Geng <[email protected]>
12. Status Of linux/802_11.h, Used By Some 3rd Party Drivers
21 Jun - 23 Jun (5 posts) Archive Link: "What happened to linux/802_11.h?"
People: Joshua Kwan, Andrew Morton, Jean Tourrilhes, James Ketrenos, David
Gibson
Joshua Kwan noticed that the linux/802_11.h file had disappeared from the
kernel sources; he asked what was up, since "The IPW2100 driver (http://
ipw2100.sourceforge.net) uses its definitions and now won't build against -bk
or -mm kernel source." Andrew Morton replied that the file had been removed
because nothing in the kernel had been using it. He asked Jean Tourrilhes,
"should we restore 802_11.h, or is there some alternative file which that
driver should be using?" Jean replied:
Well, Jeff explicitely said that we should not care about drivers outside
the kernel ;-)
Seriously, I see three solutions :
1. Convert ipw2100 to using drivers/net/wireless/ieee802_11.h, extend this
header as necessary
2. Have ipw2100 use a private version of 802_11.h
3. Convince us that this file is really needed (good luck) Obviously (1)
is better in the long term.
He also added that the linux/802_11.h file
was a remnant from the old aironet4500 driver that was removed during
2.5.X. It was also confusing because there is a file called drivers/net/
wireless/ieee802_11.h that has a somewhat similar purpose and is used in
various drivers (Orinoco, Atmel). I think it was discussed on netdev.
I was not aware that IPW2100 was using it. I could not try this driver
because it doesn't compile with gcc 2.95.
James Ketrenos said of the first of Jean's three possible solutions listed
above (converting ipw2100 to use ieee802_11.h), that "This is the path I was
planning to take when I read about 802_11.h possibly going away a while ago.
The file finally going away will just raise the priority of that effort a bit
:) Changing the code to use the headers in drivers/net/wireless isn't a big
task -- I'll put the change into the next snapshot of ipw2100." Jean was fine
with this, and added, "BTW, I'm not the one maintaining ieee802_11.h, it was
originally created by David Gibson as part of the Orinoco driver. So, if there
is something you don't like in it, you may want to contact him."
13. Precise CPU Accounting Patch Ported From 2.4 To 2.6.7
23 Jun (4 posts) Archive Link: "PATCH: Precise Accounting for 2.6.7"
People: Timm Morten Steinbeck, Andi Kleen
Timm Morten Steinbeck said:
we have ported our x86 precise accounting patch from the 2.4 kernel series
to 2.6.7.
The patch fixes a problem with the accounting via the "cpu*" lines from /
proc/stat. The standard kernels can produce misleading data for programs
that give up the rest of their timeslice, e.g. via usleep. This can lead to
programs using 90% or more CPU time which is not accounted. The computer is
reported as idle or another program seems to use up the time. The patch
fixes the problem by doing the accounting on the basis of the CPU's time
stamp counter instead of whole time slices. The patch as well as
proof-of-principle programs illustrating the problem can be downloaded at
http://www.ti.uni-hd.de/HLT/software/software.html#kernel.
Our original mail for the 2.4.20 patch is at http://lwn.net/Articles/24974/
.
Please CC all comments to timm.steinbeck AT kip.uni-heidelberg.de and
arne.wiebalck AT kip.uni-heidelberg.de, as we are not subscribed to the
LKML.
At first glance, Andi Kleen had some technical problems with this, but after
reexamining the code, he gave it his approval.
14. Status Of Preemption/Low-Latency In 2.6.7
23 Jun - 24 Jun (7 posts) Archive Link: "status of Preemptible Kernel 2.6.7"
Topics: Real-Time
People: Timothy Miller, Robert Love, Marcus Hartig
Marcus Hartig asked about the status of kernel preemption for real-time
processing in the 2.6 tree; and whether it was up to use on a normal desktop
system. Timothy Miller replied:
I vaguely recall someone recently talking about eliminating preempt by
improving low-latency. See, if everything were ideal, we wouldn't need
preempt, because all drivers would yield the CPU at appropriate times.
Supposedly, preempt introduces some undesirable overhead.
Perhaps we could turn preempt into some kind of watch-dog. If a kernel
thread doesn't behave, it gets killed. :)
Robert Love remarked, "If everything held locks for only sane periods of time,
we would not need gross explicit yielding all over the place." He also said to
Marcus that preempt would be fine on desktop systems. Later, he clarified, "it
seems better overall to me if we work to eliminate long lock hold times (which
then eliminates long non-preemption times) than litter the kernel with explicit
rescheduling statements." Timothy agreed that this would be a good thing.
15. Policy For Using GCC Built-Ins
23 Jun - 24 Jun (17 posts) Archive Link: "using gcc built-ins for bitops?"
People: Arjan van de Ven, Linus Torvalds
Arjan van de Ven said:
gcc 3.4 gained support for several typical bitops as builtin directives.
Using these over inline asm has a few advantages:
+ gcc can optimize constants into these better
+ gcc can reorder and schedule the code better
+ gcc can allocate registers etc better for the code
The question is if we consider it desirable to go down this road or not. In
order to help that discussion I've attached a patch below that switches the
i386 ffz() function to the gcc builtin version, conditional on gcc having
support for this. Before I go down the road of converting more functions
and/or architectures.... is this worth doing?
There was some initial support for this, until Linus Torvalds said:
unless the gcc code can be shown to be clearly better, it is NOT worth
doing.
Adding support for built-ins generates a noticeable maintenance burden,
since we'll still have to support older gcc's and architectures where gcc
does WORSE than we do. And quite frankly, I doubt you'll find any cases
where gcc does any better in any measurable way.
In other words, the rule about gcc builtins should be:
+ use them only if they are old enough that the huge majority (possibly
all) of users get them. This is partly because gcc has frankly been
buggy, and often makes assumptions that simply may not be true for the
kernel (ie "it's ok to use library routines").
+ only use them if you can show a measurable improvement. Theoretical
arguments simply don't count. Theoretical arguments is why gcc-3.x is a
lot slower than 2.95 and is apparently still not generating appreciably
better code for the kernel (and no, don't bother pointing me to spec
runs, I just don't care. The kernel is what I care about).
So far, the only case where they have been worth it is likely the "memcpy()
" stuff, and even there our previous macros were doing an almost equivalent
job (but were arguably so ugly that it was worth making the change).
For something like ffs/popcount/etc, I do not see _any_ point to compiler
support. There just aren't any kernel uses that make it worth it. Sounds
like a total micro-optimization for some spec benchmark.
16. Enhanced Linux System Accounting (ELSA) Updated For Linux 2.6.7
24 Jun (1 post) Archive Link: "[Patch] Enhanced Linux System Accounting for
2.6.7"
Topics: BSD, Ioctls
People: Guillaume Thouvenin
Guillaume Thouvenin said:
Here is a new patch for kernel 2.6.7. You can download it from sourceforge
at http://prdownloads.sourceforge.net/elsa/patch-2.6.7-elsa?download
This patch provides structures and functions to do accounting for a group
of process. There is two parts.
On one hand there is two APIs that allow the creation and the destruction
of an item called a "bank" that will contain an group of processes. There
is also two other routines that can add or remove processes in a bank.
On the other hand, you have the accounting mechanism that used bank to
perform BSD-like accounting for a group of process. We used ioctl()
interface to create/destroy a bank and also to add/remove a process in a
bank. Currently, device driver is dev/elsacct and the major number is
dynamically allocated, therefore you need to check the number in the /proc/
devices and create the corresponding device. A sample code is given at:
http://cvs.sourceforge.net/viewcvs.py/elsa/tests/elsa_cmd.c?rev=1.7&view=
markup
Currently we do BSD-like accounting. The next step is to identify what kind
of metrics can be interesting for accounting. We started to describe that
point on a withpaper that is available at: http://sourceforge.net/docman/
display_doc.php?docid=23446&group_id=105806 This paper describes
differences between two accounting systems that are ELSA and CSA.
Every comments are welcome,
The ELSA poject team (http://elsa.sourceforge.net)
We Hope You Enjoy Kernel Traffic
Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.