Kernel Traffic #272 by Zack Brown
[email protected] Sun, 05 Sep 2004 09:44:44 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #272 For 5 Sep
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 4 Jul - 26 Jul (55 More Sistina Software Available; Clustering
posts) Workshop Organized
2. 9 Jul - 29 Jul (267 New 'Voluntary' Preemption Patch Avoids
posts) Existing Preemption Problems
3. 13 Jul - 22 Jul (19 Linux 2.6.8-rc1-mm1 Released; Quick Fix For
posts) Big Slowdown Followed
4. 14 Jul - 29 Jul (23 I2C Updates For 2.6
posts)
5. 20 Jul - 27 Jul (13 Limiting the Number Of Concurrent Hotplug
posts) Processes
6. 22 Jul - 27 Jul (21 Possible Scheduler Improvements
posts)
7. 22 Jul - 26 Jul (2 Process Aggregates (PAGG) For Grouping
posts) Processes
8. 23 Jul (5 Joining Keyboards To Braille Displays
posts)
9. 23 Jul - 27 Jul (54 Kernel Events Layer For Asynchoronous
posts) Communication
10. 23 Jul - 24 Jul (6 ketchup Version 0.8 Released
posts)
11. 23 Jul - 29 Jul (3 GPL Being Tested In German Courts
posts)
12. 26 Jul - 27 Jul (3 Driver For IBM Multiport Serial Adapters
posts)
13. 27 Jul - 29 Jul (30 IRQ Threads; Real-Time Issues
posts)
14. 28 Jul (1 loop-AES Update
post)
15. 29 Jul (1 PPC8xx Maintainership
post)
Introduction
I'd like to thank the folks who sent me pointers to tech-writing jobs, or who
recommended me to their companies. It's making a big difference, and I really
appreciate it. Thanks!
For the moment, though, I'm still available, and anyone who wants to check out
my resume (resume.html) is more than welcome.
Mailing List Stats For This Week
We looked at 1660 posts in 10280K.
There were 432 different contributors. 222 posted more than once. 142 posted
last week too.
The top posters of the week were:
* 74 posts in 307K by Andrew Morton
* 73 posts in 304K by Ingo Molnar
* 56 posts in 339K by Lee Revell
* 53 posts in 415K by Vojtech Pavlik
* 42 posts in 212K by Nick Piggin
* Full Stats
1. More Sistina Software Available; Clustering Workshop Organized
4 Jul - 26 Jul (55 posts) Archive Link: "[ANNOUNCE] Minneapolis Cluster
Summit, July 29-30"
Topics: Clustering, Ottawa Linux Symposium
People: Daniel Phillips, Christoph Hellwig, Lars Marowsky-Bree, Arjan van de
Ven, Steven Dake, Nick Piggin, Andrew Morton
Daniel Phillips said:
Red Hat and (the former) Sistina Software are pleased to announce that we
will host a two day kickoff workshop on GFS and Cluster Infrastructure in
Minneapolis, July 29 and 30, not too long after OLS. We call this the
"Cluster Summit" because it goes well beyond GFS, and is really about
building a comprehensive cluster infrastructure for Linux, which will
hopefully be a reality by the time Linux 2.8 arrives. If we want that, we
have to start now, and we have to work like fiends, time is short. We offer
as a starting point, functional code for a half-dozen major, generic
cluster subsystems that Sistina has had under development for several
years.
This means not just a cluster filesystem, but cluster logical volume
management, generic distributed locking, cluster membership services, node
fencing, user space utilities, graphical interfaces and more. Of course,
it's all up for peer review. Everybody is invited, and yes, that includes
OCFS and Lustre folks too. Speaking as an honorary OpenGFS team member, we
will be there in force.
Tentative agenda items:
+ GFS walkthrough: let's get hacking
+ GULM, the Grand Unified Lock Manager
+ Sistina's brand new Distributed Lock Manager
+ Symmetric Cluster Architecture walkthrough
+ Are we there yet? Infrastructure directions
+ GFS: Great, it works! What next?
Further details, including information on travel and hotel arrangements,
will be posted over the next few days on the Red Hat sponsored community
cluster page:
http://sources.redhat.com/cluster/
Unfortunately, space is limited. We feel we can accommodate about fifty
people comfortably. Registration is first come, first served. The price is:
Free! (Of course.) If you're interested, please email me.
Let's set our sights on making Linux 2.8 a true cluster operating system.
Christoph Hellwig replied, "Don't you think it's a little too short-term? I'd
rather see the cluster software that could be merged mid-term on KS (and that
seems to be only OCFS2 so far)" . Daniel said that the project was not short
term; on the contrary, he felt the project was several months overdue. He
asked, "Don't you think we ought to take a look at how OCFS and GFS might share
some of the same infrastructure, for example, the DLM and cluster membership
services?" Lars Marowsky-Bree said ominously, "Indeed. If your efforts in
joining the infrastructure are more successful than ours have been, more power
to you ;-)"
Daniel asked what problems Lars was talking about, as the technical issues did
not seem insurmountable; Lars replied:
The problems were mostly political. Maybe we tried to push too early, but
1-3 years back, people weren't really interested in agreeing on some common
components or APIs. In particular a certain Linux vendor didn't even join
the group ;-) And the "industry" was very reluctant too. Which meant that
everybody spend ages talking and not much happening.
However, times may have changed, and hopefully for the better. The push to
get one solution included into the Linux kernel may be enough to convince
people that this time its for real...
There still is the Open Clustering Framework group though, which is a
sub-group of the FSG and maybe the right umbrella to put this under, to
stay away from the impression that it's a single vendor pushing.
If we could revive that and make real progress, I'd be as happy as a well
fed penguin.
Now with OpenAIS on the table, the GFS stack, the work already done by OCF
in the past (which is, admittedly, depressingly little, but I quite like
the Resource Agent API for one) et cetera, there may be a good chance.
Daniel, a Red Hat employee, admitted that Lars' reference to a "certain Linux
vendor" referred to Red Hat. But he said that Red Hat was fully behind the idea
now, and had a lot of recently acquired Sistina code to put into the pot. He
invited everyone who had expressed interest in this in the past to join in the
discussion and in the project. And he promised to look over all available
relevant code. He and Lars, during this conversation, also went back-and-forth
on various technical issues; which Daniel summarized at one point, saying:
OK, what I've learned from the discussion so far is, we need to avoid
getting stuck too much on the HA aspects and focus more on the cluster/
performance side for now. There are just too many entrenched positions on
failover. Even though every component of the cluster is designed to fail
over, that's just a small part of what we have to deal with:
+ Cluster Volume management
+ Cluster configuration management
+ Cluster membership/quorum
+ Node Fencing
+ Parallel cluster filesystems with local semantics
+ Distributed Locking
+ Cluster mirror block device
+ Cluster snapshot block device
+ Cluster administration interface, including volume managment
+ Cluster resource balancing
+ bits I forgot to mention
Out of that, we need to pick the three or four items we're prepared to
address immediately, that we can obviously share between at least two known
cluster filesystems, and get them onto lkml for peer review. Trying to push
the whole thing as one lump has never worked for anybody, and won't work in
this case either. For example, the DLM is fairly non-controversial, and
important in terms of performance and reliability. Let's start with that.
Furthermore, nobody seems interested in arguing about the cluster block
devices either, so lets just discuss how they work and get them out of the
way.
Then let's tackle the low level infrastructure, such as CCS (Cluster
Configuration System) that does a simple job, that is, it distributes
configuration files racelessly.
I heard plenty of fascinating discussion of quorum strategies last night,
and have a number of papers to read as a result. But that's a diversion: it
can and must be pluggable. We just need to agree on how the plugs work, a
considerably less ambitious task.
In general, the principle is: the less important it is, the more argument
there will be about it. Defer that, make it pluggable, call it policy, push
it to user space, and move on. We need to agree on the basics so that we
can manage network volumes with cluster filesystems on top of them.
The technical discussion continued, with contributions from Daniel, Lars, Arjan
van de Ven, Nick Piggin, Steven Dake, and even a small contribution from Andrew
Morton.
2. New 'Voluntary' Preemption Patch Avoids Existing Preemption Problems
9 Jul - 29 Jul (267 posts) Archive Link: "[announce] [patch] Voluntary Kernel
Preemption Patch"
Topics: FS: ReiserFS, FS: ext3, Framebuffer, Real-Time, SMP, Sound: ALSA
People: Ingo Molnar, Andrew Morton, Robert Love, Arjan van de Ven, Mikulas
Patocka
Ingo Molnar said:
as most of you are probably aware of it, there have been complaints on lkml
that the 2.6 kernel is not suitable for serious audio work due to high
scheduling latencies (e.g. the Jackit people complained). I took a look at
latencies and indeed 2.6.7 is pretty bad - latencies up to 50 msec (!) can
be easily triggered using common workloads, on fast 2GHz+ x86 system - even
when using the fully preemptible kernel!
to solve this problem, Arjan van de Ven and I went over various kernel
functions to determine their preemptability and we re-created from scratch
a patch that is equivalent in performance to the 2.4 lowlatency patches but
is different in design, impact and approach:
http://redhat.com/~mingo/voluntary-preempt/voluntary-pree mpt-2.6.7-bk20-H2
(http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H2
)
(Note to kernel patch reviewers: the split voluntary_resched type of APIs,
the feature #ifdefs and runtime flags are temporary and were only
introduced to enable a easy benchmarking/comparisons. I'll split this up
into small pieces once there's testing feedback and actual audio users had
their say!)
unlike the lowlatency patches, this patch doesn't add a lot of new
scheduling points to the source code, it rather reuses a rich but currently
inactive set of scheduling points that already exist in the 2.6 tree: the
might_sleep() debugging checks. Any code point that does might_sleep() is
in fact ready to sleep at that point. So the patch activates these
debugging checks to be scheduling points. This reduces complexity and
impact quite significantly.
but even using these (over one hundred) might_sleep() points there were
still a number of latency sources in the kernel - we identified and fixed
them by hand, either via additional might_sleep() checks, or via explicit
rescheduling points. Sometimes lock-break was necessary as well.
as a practical goal, this patch aims to fix all latency sources that
generate higher than ~1 msec latencies. We'd love to learn about workloads
that still cause audio skipping even with this patch applied, but i've been
unable to generate any load that creates higher than 1msec latencies. (not
counting driver initialization routines.)
this patch is also more configurable than the 2.4 lowlatency patches were:
there's a .config option to enable voluntary preemption, and there are
runtime /proc/sys knobs and boot-time flags to turn voluntary preemption
(CONFIG_VOLUNTARY_PREEMPT) and kernel preemption (CONFIG_PREEMPT) on/off:
# turn on/off voluntary preemption (if CONFIG_VOLUNTARY_PREEMPT)
echo 1 > /proc/sys/kernel/voluntary_preemption
echo 0 > /proc/sys/kernel/voluntary_preemption
# turn on/off the preemptible kernel feature (if CONFIG_PREEMPT)
/proc/sys/kernel/kernel_preemption
/proc/sys/kernel/kernel_preemption
the 'voluntary-preemption=0/1' and 'kernel-preemption=0/1' boot options can
be used to control these flags at boot-time.
all 4 combinations make sense if both CONFIG_PREEMPT and
CONFIG_VOLUNTARY_PREEMPT are enabled - great for performance/latency
testing and comparisons.
The stock 2.6 kernel is equivalent to:
voluntary_preemption:0 kernel_preemption:0
the 2.6 kernel with voluntary kernel preemption is equivalent to:
voluntary_preemption:1 kernel_preemption:0
the 2.6 kernel with preemptible kernel enabled is:
voluntary_preemption:0 kernel_preemption:1
and the preemptible kernel enhanced with additional lock-breaks is enabled
via:
voluntary_preemption:1 kernel_preemption:1
it is safe to change these flags anytime.
The patch is against 2.6.7-bk20, and it also includes fixes for kernel bugs
that were uncovered while developing this patch. While it works for me, be
careful when using this patch!
A huge discussion ensued. There was a good bit of support initially among some
developers, and a lot of folks piled on with comments and criticisms. But
Andrew Morton did not feel that the situation was at all clear. He thought it
would be useful to examine the particular workloads that folks had experienced
when the problems occurred; and he said:
Certainly 2.6+preempt is not as good as 2.4+LL at this time, but 2.6 isn't
too bad either. Even under heavy filesystem load it's hard to exceed a 0.5
millisecond holdoff. There are still a few problem in the ext3 checkpoint
buffer handling, but those seem pretty hard to hit. I doubt if the `Jack'
testers were running `dbench 1000' during their testing.
All of which makes me suspect that the problems which the `Jack' testers
saw were not directly related to long periods of non-preemption in-kernel.
At least, not in core kernel/fs/mm code. There have been problem in the
past in places like i2c drivers, fbdev scrolling, etc.
What we need to do is to encourage audio testers to use ALSA drivers, to
enable CONFIG_SND_DEBUG in the kernel build and to set /proc/asound/*/*/
xrun_debug and to send us the traces which result from underruns.
As for the patch, well, sprinkling rescheduling points everywhere is still
not the preferred approach. But adding more might_sleep() checks is a
sneaky way of making it more attractive ;)
In a nearby post he also added:
Let me repeat that I am unconvinced as to the diagnosis of the current
audio problems - more analysis might prove me wrong of course.
And I'm unconvinced that we need to do anything apart from identifying and
fixing the remaining spinlocks which are holding off preemption for too
long.
IOW, I am questioning the very need for a "voluntary preemption" feature at
all when "involuntary preemption" works perfectly well.
A few posts down the road, Ingo replied:
the reason is difference in overhead (codesize, speed) and risks (driver
robustness). We do not want to enable preempt for Fedora yet because it
breaks just too much stuff and is too heavy. So we looked for a solution
that might work for a generic distro.
here are the code size differences. With a typical .config (debugging
options disabled), the 2.6.7-mm7(+voluntary-preempt) UP x86 kernel gets the
following .text sizes:
orig: 1776911 bytes
preempt: 1855519 bytes (+4.4%)
voluntary: 1783407 bytes (+0.3%)
so if voluntary-preempt can get close to real preempt's numbers for
practical stuff then we get most of the benefits while excluding some of
the nastiest risks and disadvantages.
(Long-term i'd like to see preempt be used unconditionally - at which point
the 10-line CONFIG_VOLUNTARY_PREEMPT Kconfig and kernel.h change could go
away.)
Robert Love suggested that in this case, instead of coming up with complicated
workarounds, the thing to do was to work on getting preemption working on
Fedora. He also disagreed with the idea that preemption would have too much
overhead associated with it. He said, "I have seen no specific arguments that
show a significant overhead. Heck, when people tried to show that kernel
preemption hurt throughput, we saw tests that showed improved throughput
(probably due to better utilization of I/O)." Andrew also added, close by, "I
don't recall any testing results which showed a significant performance
difference from CONFIG_PREEMPT." He also felt the thing to do was to fix
preemption on Fedora, or at least identify the bugs so they could be addressed.
Arjan van de Ven replied, "just look over all the "fix preempt" stuff that got
added to the kernel in the last 6 months. Sometimes subtle sometimes less so.
>From a distribution POV I don't want a potential slew of basically impossible
to reproduce problems, especially this young in 2.6, there are plenty of other
problems already (and before you ask "which", just look at how many bugs got
fixed in the last X weeks for any value of X, and look at say acpi issues). Yes
I understand this puts you into a bit of a bad position, several distros not
enabling preempt means that it gets less testing than it should. However..
there's only so much issues distros can take and with 2.6 still quite fresh..."
Andrew felt that Arjan was equivocating here; and suggested that Arjan really
couldn't identify any specific bugs and was just spreading FUD. Mikulas Patocka
replied with a concrete case. He said, "For example the recent race that
corrupted file content on ext3 and reiserfs when fsync and write were called
simultaneously ... it was possible on SMP too, but with tiny probability ---
CONFIG_PREEMPT triggered it wide open." But there was no reply to this.
Elsewhere, some audio folks actually followed Andrew's initial suggestion of
performing more tests, and so a large subthread was taken up with preemption
debugging session. Throughout the discussion, Andrew reiterated that
"preemption is the way in which we wish to provide low-latency. At this time,
patches which sprinkle cond_resched() all over the place are unwelcome. After
2.7 forks we can look at it again." Though even then he affirmed that he had
not yet gone over Ingo's and Arjan's patch.
Elsewhere, and sometimes overlapping with the preempt discussion, Ingo and
Arjan continued to develop and release new versions of their patch.
3. Linux 2.6.8-rc1-mm1 Released; Quick Fix For Big Slowdown Followed
13 Jul - 22 Jul (19 posts) Archive Link: "2.6.8-rc1-mm1"
Topics: Big Memory Support, FS: ext3, Kernel Release Announcement, Ottawa Linux
Symposium
People: Andrew Morton, J. A. Magallon, Jens Axboe
Andrew Morton announced Linux 2.6.8-rc1-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/ akpm/patches/2.6/2.6.8-rc1/
2.6.8-rc1-mm1/ (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/
2.6/2.6.8-rc1/2.6.8-rc1-mm1/)
+ Lots of little fixes, mainly
+ Numerous scheduling latency fixes, mainly in the ext3 area.
This is a first pass - these patches need redoing and a bit of
infrastructure consolidation.
+ Outta here: I won't be in a position to handle patches until July 26.
Off to http://www.tech-forum.org/upcoming/open_source_software_06-10
-04.htm (http://www.tech-forum.org/upcoming/
open_source_software_06-10-04.htm) and then Kernel Summit and then OLS.
He posted a quick patch six hours later, at around midnight, saying, "This
kernel runs like a dessicated slug if you have more than 2G of memory due to a
32-bit overflow." He acknowledged that it wasn't a great fix, but it would do
for the moment. Elsewhere, J. A. Magallon reported that 2.6.8-rc1-mm1 would
oops if the user tried to write to a CD without a CD in the driver. He said:
Who would do such a stupid thing ? Me the impatient trying to write before
the drive ends to load the disc...
The bad thing is that it leaves the drive in an ususable state:
Error trying to open /dev/hdc exclusively (Device or resource busy)... retrying in 1 second.
Error trying to open /dev/hdc exclusively (Device or resource busy)... retrying in 1 second.
It does not happen with 2.6.8-rc2.
Jens Axboe posted a fix, adding that Andrew did have possession of the fix,
though Jens wasn't sure if it had actually been merged yet.
4. I2C Updates For 2.6
14 Jul - 29 Jul (23 posts) Archive Link: "[BK PATCH] I2C update for 2.6.8-rc1
"
Topics: FS: sysfs
People: Greg KH, Mark M. Hoffman, Jean Delvare
Greg KH, working with Alexandre d'Alton, Eugene Surovegin, Luiz Capitulino,
Andras Bali, Mark M. Hoffman, and primarily with Jean Delvare, posted a bunch
of I2C patches, split up into bite-sized chunks for easy approval. He said,
"Here are some i2c driver fixes and updates for 2.6.8-rc1. There are a few new
i2c chip drivers, and the biggest chunk is the new w1 (1-wire) driver subsystem
contributed by Evgeniy Polyakov. The sysfs interface for w1 isn't finished
quite yet (just need to create some more sysfs files, nothing major), but the
main functionality is there, and this allows more w1 drivers to be contributed
easier." One patch aimed at providing support for adm1030 and adm1031 sensors
chips. Another, as Greg said, "adds support for the LM86, MAX6657 and MAX6658
sensor chips to the lm90 driver. These are less popular than the LM90 and
ADM1032 but several users have reported to use these, so I added support to the
lm90 driver. All these chips are fully compatible so that's just a matter of
accepting the new chip ids. I also slightly simplified the detection code."
Another, as Greg said, "adds support for the LM77 sensor chips made by National
Semiconductor. Formerly this was claimed by the LM75 driver but when I got hold
of an embedded board (built around the National Geode SC1100 CPU), which was
equipped with an LM77, it turned out that the two chips are not compatible."
Another, as Greg said, "is my port of the adm1025 driver to 2.6. It has been
tested by a few users and reported to work OK." Another patch added a Dallas
1-wire protocol driver subsystem. As stated in the configuration help text
included in the patch, "Dallas's 1-wire bus is usefull to connect slow 1-pin
devices such as iButtons and thermal sensors." The remaining patches were bug
fixes and documentation updates (and the removal of i2c/i2c-pport documentation
because the relevant driver was not in the official sources and had not yet
even been ported to 2.6).
5. Limiting the Number Of Concurrent Hotplug Processes
20 Jul - 27 Jul (13 posts) Archive Link: "[PATCH] Limit number of concurrent
hotplug processes"
Topics: Hot-Plugging, Virtual Memory
People: Hannes Reinecke, Christian Borntraeger, Andrew Morton
Hannes Reinecke said:
the attached patch limits the number of concurrent hotplug processes. Main
idea behind it is that currently each call to call_usermodehelper will
result in an execve() of "/sbin/hotplug", without any check whether enough
resources are available for successful execution. This leads to hotplug
being stuck and in worst cases to machines being unable to boot.
This check cannot be implemented in userspace as the resources are already
taken by the time any resource check can be done; for the same reason any
'slim' programs as /sbin/hotplug will only delay the problem.
Andrew Morton was a little surprised to hear about Hannes' symptoms. He asked
what was causing enough module probes to trigger the lockup. Christian
Borntraeger replied:
I dont know exactly which scenario Hannes has seen, but its quite simple to
trigger this scenario with almost any s390/zSeries.
Using the Hardware Management Console or z/VM you are able to hotplug
(deactive/activate/attach/detach) almost every channel path. As a channel
path can connect a big bunch of devices lots of machine checks are
triggered, which causes lots of hotplugs. The same amount of machine checks
could happen if a hardware failure happens.
Some month ago I played around with a diet version of hotplug. This program
was fast and small enough to make my scenario work properly. Nevertheless,
as hannes already stated this will only delay the problem.
And Hannes confirmed, "As Christian Borntraeger already said, it's not so much
an explosion of module probes but rather the triggering of quite a lot of
events. Imagine loading scsi_debug with 512 devices or more ..."
Andrew and Hannes went back and forth on it for a bit, but had a strange sort
of disconnect, in which Andrew wasn't able to understand what Hannes was
attempting, and Hannes wasn't able to explain it clearly. Patches came in from
both sides throughout, and the thread ended abruptly, with no conclusion.
6. Possible Scheduler Improvements
22 Jul - 27 Jul (21 posts) Archive Link: "[RFC] Patch for isolated scheduler
domains"
Topics: Hyperthreading, SMP
People: Dimitri Sivanich, Ingo Molnar, Nick Piggin
Dimitri Sivanich said:
I'm interested in implementing something I'll call isolated sched domains
for single cpus (to minimize the latencies involved when doing things like
load balancing on certain select cpus) on IA64.
Below I've included an initial patch to illustrate what I'd like to do. I
know there's been mention of 'platform specific work' in the area of sched
domains. This patch only addresses IA64, but could be made generic as well.
The code is derived directly from the current default
arch_init_sched_domains code.
The patch isolates cpus that have been specified via a boot time parameter
'isolcpus=<cpu #>,<cpu #>'.
Ingo Molnar liked the idea, and suggested, "put it into sched.c. Every
architecture benefits from the ability to define isolated CPUs." Nick Piggin
asked if Dimitri or anyone else had tried actually running the code, and
Dimitri said he'd been running it on an Altix. Nick also pointed him to a
thread Nick had started, with Subject: "[PATCH] consolidate sched domains (
http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&selm=
2kYV2-RS-3%40gated-at.bofh.it) ", and suggested that Dimitry consider working
on top of the patch Nick described there.
In that thread, Nick said:
The attached patch is against 2.6.8-rc1-mm1. Tested on SMP, UP and SMP+HT
here and it seems to be OK.
I have included the cpu_sibling_map for ppc64, although Anton said he did
have an implementation floating around which he would probably prefer, but
I'll let him deal with that.
Anyway, x86-64 is not equivalent before and after this patch. The main
thing is that they've been using SD_CPU_INIT for NUMA nodes, but will now
use SD_NODE_INIT. Probably neither is optimal, but I don't think Andi has
had much time to look at it. I should be able to take a look at it soon.
Nick's changelog entry for the patch read:
Teach the generic domains builder about SMT, and consolidate all
architecture specific domain code into that. Also, the SD_*_INIT macros can
now be redefined by arch code without duplicating the entire setup code.
This can be done by defining ARCH_HASH_SCHED_TUNE.
The generic builder has been simplified with the addition of a helper macro
which will probably prove to be useful to arch specific code as well and
should be exported if that is the case.
Dimitri waded into the code, asking questions and offering bug reports, along
with several other developers.
7. Process Aggregates (PAGG) For Grouping Processes
22 Jul - 26 Jul (2 posts) Archive Link: "[PATCH] (update) Process Aggregates
(PAGG) for 2.6.7"
Topics: SMP
People: Erik Jacobson, Andrew Morton
For an earlier PAGG patch, see Issue #190, Section #10 (17 Oct 2002: CSA
System Resource Accounting Tool)
This time, Erik Jacobson said:
Attached is the PAGG patch for kernel 2.6.7. Some may recall I posted an
earlier PAGG patch for 2.6.7. This version has improved handling for the
init function pointer functionality introduced earlier.
We'd be very interested in seeing this be accepted in to the kernel. If
there is anything we should adjust to make it more likely to be accepted,
please reply.
The patch included documentation as well, in the form of a Documentation/
pagg.txt file:
The process aggregates infrastructure, or PAGG, provides a generalized
mechanism for providing arbitrary process groups in Linux. PAGG consists of
a series of functions for registering and unregistering support for new
types of process aggregation containers with the kernel. This is similar to
the support currently provided within Linux that allows for dynamic support
of filesystems, block and character devices, symbol tables, network
devices, serial devices, and execution domains. This implementation of PAGG
provides developers the basic hooks necessary to implement kernel modules
for specific process containers, such as the job container.
The do_fork function in the kernel was altered to support PAGG. If a
process is attached to any PAGG containers and subsequently forks a child
process, the child process will also be attached to the same PAGG
containers. The PAGG containers involved during the fork are notified that
a new process has been attached. The notification is accomplished via a
callback function provided by the PAGG module.
The do_exit function in the kernel has also been altered. If a process is
attached to any PAGG containers and that process is exiting, the PAGG
containers are notified that a process has detached from the container. The
notification is accomplished via a callback function provided by the PAGG
module.
The sys_execve function has been modified to support an optional callout
that can be run when a process in a pagg list does an exec. It can be used,
for example, by other kernel modules that wish to do advanced CPU placement
on multi-processor systems (just one example).
Andrew Morton replied, "Seems straightforward enough, but until we've decided
to merge features which actually _use_ the mechanism, I'd be reluctant to send
any of this Linuswards."
8. Joining Keyboards To Braille Displays
23 Jul (5 posts) Archive Link: "User-space Keyboard input?"
People: Mario Lang, Marcel Holtmann, Samuel Thibault
Mario Lang said:
I'm working on BRLTTY[1], a user-space daemon which handles braille
displays on UNIX platforms. One of our display drivers recently gained the
ability to receive (set 2) scancodes from a keyboard connected directly to
the display. This is a very cool feature, since the display in question has
a bluetooth interface, making it effectively into a complete wireless
terminal (input and output through the same connection).
However, this creates some problems. First of all, we now have to deal with
keyboard layouts. Additionally, since we currently insert via TIOCSTI I
think this might get problematic as soon as one switches to an X Windows
console and modifiers come into play.
Does anyone know (and can point me into the right direction) if Linux has
some mechanism to allow for user-space keyboard data to be processed by the
kernel as if it were received from the system keyboard? I.e., keyboard
layout would be handled by the same mapping which is configured for the
system.
Marcel Holtmann suggested, "Take a look at the user level driver support
(uinput)." And Samuel Thibault also said to Mario:
About modifiers, I submitted a patch to Dave to handle them properly.
But ascii to scancode translation still depends on scancode to ascii
translation performed by the kernel indeed and the question still applies.
I'll have a look at uinput.
Several days later, Mario posted an update, "uinput support is now committed to
scr_linux.c. I am using the exernal keyboard of my bluetooth capable braille
display to type this email already via uinput :-). The same layout is used as
is configured on the box. Our generic AT2 support maps to VAL_PASSKEY commands
and the AT2 support for Linux maps the AT2 scancode set to what Linux
internally uses for scancodes (a sort of XT scancode set, but not really)."
9. Kernel Events Layer For Asynchoronous Communication
23 Jul - 27 Jul (54 posts) Archive Link: "[patch] kernel events layer"
Topics: FS: sysfs
People: Robert Love, Chris Wedgwood, Andrew Morton, Greg KH, Inaky
Perez-Gonzalez
Robert Love said:
Following patch implements the kernel events layer, which is a simple
wrapper around netlink to allow asynchronous communication from the kernel
to user-space of events, errors, logging, and so on.
Current intention is to hook the kernel via this interface into D-BUS,
although the patch is intended to be agnostic to any of that and policy
free.
D-BUS can be found here:
http://dbus.freedesktop.org/
Other user-space utilities (including code to utilize this) can be found
here:
http://vrfy.org/projects/kdbusd/
This patch only implements a single event, processor temperature detection.
Other useful events include md sync, filesystem mount, driver errors, etc.
We can add those later, on a case-by-case basis. I would like to be more
careful with adding events than we are with adding printk's, with some aim
toward a stable interface.
Usage of the new interface is simple:
send_kmessage(group, interface, message, ...)
Credit to Arjan for the initial implementation, Kay Sievers for some
updates, and the netlink code.
A lot of folks went over the patch and offered comments and criticism; Andrew
Morton also asked approximately how many send_kmessage() calls there were
likely to be in total, in a couple of years. Robert replied:
Predicting the future is hard, but I suspect this number to be small. Let's
say 10 in core kernel code?
If this takes off as a solution for error reporting, that number will be
much larger in drivers.
Chris Wedgwood was OK with the 10 calls in the core kernel, but a large number
in driver code would worry him. He said:
I would alsmost rather all possible messages get stuck somewhere common so
driver writes can't add these ad-hoc and we can avoid a proliferation of
either similar or pointless messages.
Forcing these into a common place lets people eyeball if a new messages
really is necessary --- and it makes writing applications to deal with
these things easier (since you don't have to scan the entire kernel tree).
Robert compared the send_kmessage() situation with that of printk()s, in that
printk() messages were intended simply to be messages the developer thought
worthwhile to post. The send_kmessage() call would presumably be similar. But
he still agreed that refining and collecting them into a single group might
make sense as well. He said, "the common base of errors could be certified as
supported by the error daemon, translated, etc. etc. I am not sure how
realistic this goal is, but I do like it, at least for the general case of the
usual errors in drivers." Chris guessed that most messages would be selected
from a small pool of common errors. The discussion continued, but at one point
Andrew Morton said:
I must say that my gut feeling here is that bolting an arbitrary new
namespace into the kernel in this manner is not the way to proceed.
I hope we'll hear more from Greg on this next week - see if we can come up
with some way to use the kobject/sysfs namespace for this.
Although heaven knows how "tmpfs just ran out of space" would map onto
kobject/sysfs.
Inaky Perez-Gonzalez suggested using kobject representations if any existed for
a given circumstance, and dealing with other situations on a case-by-case
basis. But Robert said, "That introduces two orthogonal name spaces, and that
really doesn't cut it. If Greg can come up with a solution for using kobjects,
I am all for that - that would be great - but I really do not see kobject paths
working out. I think the best we have is the file path in the tree." Greg KH
replied, "Give me a few days, I'm working on it, but have been traveling too
much. Robert and I will sit down during OSCON this week and try to work out
something along these lines, and then post it again here."
10. ketchup Version 0.8 Released
23 Jul - 24 Jul (6 posts) Archive Link: "[ANNOUNCE] ketchup 0.8"
People: Matt Mackall
Matt Mackall said:
ketchup is a script that automatically patches between kernel versions,
downloading and caching patches as needed, and automatically determining
the latest versions of several trees. Available at:
http://selenic.com/ketchup/ketchup-0.8
New in this version by popular demand:
+ falls back to .gz files if .bz2 files aren't available
+ can find BK snapshots in old/ directories (aka the jgarzik memorial
hack)
+ option to rename directories to linux-<v> after update
+ can read default options from KETCHUP_OPTS
Example usage:
$ ketchup 2.6-mm
2.6.3-rc1-mm1 -> 2.6.5-mm4
Applying 2.6.3-rc1-mm1.bz2 -R
Applying patch-2.6.3-rc1.bz2 -R
Applying patch-2.6.3.bz2
Applying patch-2.6.4.bz2
Applying patch-2.6.5.bz2
Downloading 2.6.5-mm4.bz2
Downloading 2.6.5-mm4.bz2.sign
Verifying signature...
gpg: Signature made Sat Apr 10 21:55:36 2004 CDT using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key
<[email protected] (mailto:[email protected]) >"
gpg: aka "Linux Kernel Archives Verification Key
<[email protected] (mailto:[email protected]) >"
owner.
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
Applying 2.6.5-mm4.bz2
Lee Revell gave ketchup a try, but had trouble getting it to work under Debian
Unstable; and the two of them went back and forth on it for a bit.
11. GPL Being Tested In German Courts
23 Jul - 29 Jul (3 posts) Archive Link: "[OT] German court says the GPL is
effective"
People: Adrian Bunk, Prakash K. Cheemplavam, Matthias Andree
Adrian Bunk said:
I know this is off-topic, but a court in my home town Munich has decided
that a cease and desist letter Harald Welte sent to a router producer
(Sitecom) who used netfilter/iptables in his router but didn't publish the
sources of the firmware with a penalty of up to 100 000 Euro is valid (a
German version of the decision of the three judges is at http://www.jbb.de/
urteil_lg_muenchen_gpl.pdf).
It's quite nice to hear that a court has decided that the GPL is
enforceable under German law.
Prakash K. Cheemplavam remarked, "As far as I have understood it: This was just
a "quick" decision making, a "real" court case comes later. So far the court
finds it reasonable to enforce the cease and desist letter until the final
decision comes, as the "probability" is high, that the GPL is compatible with
German laws and even if not, the company wouldn't be allowed to use the GPLed
software."
Matthias Andree asked if the verdict had become final yet, and Adrian replied
that no, it had not.
12. Driver For IBM Multiport Serial Adapters
26 Jul - 27 Jul (3 posts) Archive Link: "new device driver to enable the IBM
Multiport Serial Adapter in Linux"
Topics: Modems
People: Janice M. Girouard, Andrew Morton, Jeff Garzik
Janice M. Girouard said:
The patch below enables the IBM Multiport Serial Adapter for the Linux OS.
This driver is for a family of multiport serial adapters including 2 port
RVX, 2 port internal modem, 4 port internal modem and a split 1 port RVX
and 1 port internal modem. We have applied & tested this patch against our
iSeries and pSeries machines (there are no known existing defects following
this testing).
We would like this code accepted into the kernel. It was previosly
submitted to the linux-serial mailing list, and we believe we have
addressed any coding issues raised. Are there any additional concerns? How
do you suggest we proceed to have this code accepted?
Andrew Morton replied:
Looks sane. Did you really intend that it be buildable for all
architectures? (There's nothing wrong with this - it's good. But it's a bit
unusual for this sort of driver).
"IBM multiport serial adapter" seems to be a rather generic description of
this device. Is this the only multiport serial adapter which IBM has ever,
or will ever make? If not, then perhaps we could make the description a
little more specific?
There was no reply to this, but elsewhere, Jeff Garzik gave a line-by-line code
commentary, with many suggestions and bug reports.
13. IRQ Threads; Real-Time Issues
27 Jul - 29 Jul (30 posts) Archive Link: "[patch] IRQ threads"
Topics: BSD, Disks: IDE, Microkernels: Adeos, Patents, Real-Time: RTAI, SMP
People: Scott Wood, Ingo Molnar, Bill Huey, Karim Yaghmour, Philippe Gerum,
Albert D. Cahalan
Scott Wood said:
I have attached a patch for implementing IRQ handlers in threads, for
latency-reduction purposes. It requires that softirqs must be run in
threads (or else they could end up running inside the IRQ threads, which
will at the very least trigger bugs due to in_irq() being set). I've tested
it with Ingo's voluntary-preempt J7 patch, and it should work with the
TimeSys softirq thread patch as well (though you might get a conflict with
the PF_IRQHANDLER definition; just merge them into one).
Some notes:
1. This may not work properly with some interrupt controller code, which
doesn't do the obvious thing with mask_and_ack() and end(). This
includes the IO-APIC code, which has an empty end() for edge triggered
interrupts and an empty mask_and_ack() for level-triggered interrupts.
The mask_and_ack() needs to really mask the interrupt, as otherwise the
hardware will not deliver lower-priority (to it) interrupts, which may
have a higher-priority thread.
2. This patch does not disable local interrupts when running a threaded
handler. SMP-safe drivers shouldn't be directly bothered by this (as
the interrupt could as easily have happened on another CPU), but there
may be some interactions with softirqs and per-cpu data, if a softirq
thread preempts an IRQ thread, or an IRQ thread gets migrated to a
different CPU. I'm particularly worried about the network code. If
possible, I'd like to find and fix such breakages rather than use
local_irq_disable(), as that would prevent IRQ proritization from
working, and prevent IRQ threads from being used to isolate the rest of
the system from long-running IRQs (such as non-DMA IDE).
3. The i8042 driver had to be marked SA_NOTHREAD, as there are
non-preemptible regions where it spins, waiting for an interrupt.
Ideally, this driver (and others like it) should be fixed to either do
a cond_resched() or use a wait queue.
4. This might be a good time to get around to moving the bulk of the arch/
whatever/kernel/irq.c into generic code, as the code said was supposed
to happen in 2.5. This patch is currently only for x86 (though we've
run IRQ threads on many different platforms in the past).
5. Is there any reason why an IRQ controller might want to have its end()
called even if IRQ_DISABLED or IRQ_INPROGRESS is set? It'd be nice to
merge those checks in with the IRQ_THREADPENDING/IRQ_THREADRUNNING
checks.
6. This patch causes in_irq() to return true if an IRQ thread is running,
as some drivers use it in common code to determine how to act.
in_interrupt(), however, will return false in such a case. The exact
meaning of these macros in the presence of IRQ threads isn't very well
defined, and I hope this results in sane behavior.
Ingo Molnar had some specific criticisms, but affirmed, "I agree with the
concept of using multiple threads for interrupts - i'll add that to the
voluntary-preempt patch too. This is an essential feature to prioritize
interrupts." Bill Huey remarked, "The way I picture the problem permits those
threads to migration across CPUs and therefore kill interrupt performance from
cache thrashing. Do you have a solution for that ? I like the way you're doing
it now with irqd() in that it's CPU-local, but as you know it's not priority
sensitive." Scott replied:
Wouldn't the IRQ threads be subject to the same heuristics that the
scheduler uses with ordinary threads, in order to avoid unnecessary CPU
migration? Plus, IRQs ordinarily get distributed across CPUs, and in most
cases shouldn't have a very large cache footprint (especially data; the
code can be in multiple CPU caches at once), so I don't think this is a
susbtantial degradation from the way things already are.
If desired by the user, an IRQ thread could be bound to a specific CPU to
avoid such problems (in which case, they'd probably want to set the
smp_affinity of the hard IRQ stub to the same CPU).
Bill replied, "I get a number of gripes from SMP aware folks that the context
switching overhead is significant as well as cache issues. That's what the
concern is about." He agreed with Scott's suggestion to bind IRQ threads to
specific CPUs, saying, "this is an obvious next step in order to get better
performance." Ingo, on the other hand, said of Scott's suggestion, "i fixed
this problem in -M5 the other way around: the IRQ threads follow the affinity
settings. They will bind themselves to the first CPU in the affinity mask and
they migrate only at 'safe' points (between hardirqs). This way e.g. user-space
irqbalance will automatically move the IRQ threads around too."
Elsewhere, in respons to Scott's original post, Karim Yaghmour leveled some
criticism, saying:
My experience with clients who have been using TimeSys' stuff has been
abysmal. The fact of the of the matter is that most people who used this
were practically locked-in to TimeSys' services, unable to download
anything "standard" off the net and using it with their kernel. In one
example, we had to ditch the kernel the client got from TimeSys because we
had spent 10+ hours trying to get LTT to work on it without any success
whatsoever.
As I had said on other lists before, I don't see the point of creating that
much complexity in the kernel in order to try to shave-off a little bit
more off of the kernel's interrupt response time. The fact of the matter is
that neither this patch nor most of the other patches suggested makes the
kernel truely hard-rt. These patches only make the kernel respond "faster".
If you really need hard-rt, then you should be using the Adeos nanokernel.
With Adeos, you can even get a hard-rt driver without using RTAI or any of
the other rt derivatives.
Lee Revell objected to Karim's vague characterizations of TimeSys, saying it
was difficult to defend against such assertions; Karim agreed, but said it was
the only way he could make the point he wanted to make, without violating his
client's confidentiality. Lee cautioned Karim to just try to be more careful in
future; and that particular disagreement ended.
Bringing the discussion back on track, Bill said:
there's really two camps that are emerging in the real time Linux field,
dual and single kernel. The single kernel work that's current being done
could very well get Linux to being hard RT, assuming that you solve all of
the technical problems with things like RCU, etc... in 2.6.
The dual kernels folks would be in less of position to VAR their own stuff
and sell proprietary products if Linux were to get native hard RT
performance if you accept that economic criteria. Who knows what the actual
results will be.
It could be that all of this work with Linux could bury prioprietary OS
product (such as LynxOS here) or it could open doors to other things
unknown things that were never possible previous to Linux getting some kind
of hard RT capability. It's certainly a scary notion to think about with
many variables to consider. Linux getting hard RT is inevitable. It's just
a question of how it'll be handled by proprietary OS vendors, witness IBM
for a positive example. A negative one would be Sun.
Now that Windriver System (the idiot folks that never understood Linux
before laying off tons of folks and disbanned the rather famous BSD/OS
group which I was apart of, etc...) and Red Hat is in the picture, it's all
starting to cook up.
Karim pointed out that the dual-kernel concept was patented; and reiterated
that he advocated a third approach: the Adeos nanokernel. Philippe Gerum also
said:
The hard RT people I know of and work with want to be able 1) to get
microsecond level bounded interrupt latency with no exception to this rule,
and 2) to be able to choose the right level of dispatch latency on a
thread-by-thread basis, from a few microseconds to a few hundreds of, but
in any case _bounded_ and predictable in the worst case. For this to
happen, they are willing to accept stringent limitations functionaly-wise
if need be to obtain the first, but still get access to the regular Linux
programming model and APIs if the second fits their apps. They already know
how they could mix both properly in what would look like a single system
from the application pov.
For these people, the current undergoing work aimed at improving the
current determinism of the vanilla kernel is everything but a danger: it's
fundamental and very good news, because it could make 2) a reality sooner
or later. However, point 1) remains an issue, and unless you find a
solution for mixing fire and water, i.e. determinism which requires
unfairness by design and throughput seeking fairness on the average case,
you would likely end up considering that the Linux RT people's radical
approach of using a dual-kernel does not make them uneducated bozos (Ok,
except me perhaps, but this is not my point). To get microsecond level
guaranteed interrupt latencies, the problem is far beyond solving random
latency spots here and there: it's an architectural issue.
To achieve this, we (i.e. the educated ones like Karim helping the
uneducated bozo like myself; yep, this is a teamwork) have come to the
conclusion that we needed a portable infrastructure that allows a complete
prioritization of interrupts, and hw events of interest in general (e.g.
traps/exceptions). Some infrastructure that exposes the same interface
regardless of the platform it runs on. It's called Adeos, the source code
identation is terrible (after 20 years practicing it, I still find means to
worsen my coding style, funky eh?!) but it's a working example of such kind
of infrastructure. The advantage of such kind of thin layer is that you can
plug any hard real-time core over it. This layer can remain silent when
unused, it can be configured out, it is just an enabler. You don't have to
put the hell of a havoc in a stable GPOS core to modify some key
architectural characteristics of the Linux kernel in order to buy hard RT
capabilities to everyone, which could be construed as smashing a squadron
of flies with nukes.
Elsewhere but close by, Albert D. Cahalan said:
There is no such thing as hard-RT in the real world.
In reality, there's no point in making the software far more reliable than
the hardware, power supply, and so on. Somebody may pour a can of Mountain
Dew into the vent holes.
Your software is OK as long as other causes of failure are much more
likely. One might even say you spent too much of your budget perfecting the
software! In the end it all comes down to $$$ (or Euros, or Yen...),
doesn't it?
People don't mathematically demonstrate anything about modern systems, at
least not while being honest.
The thread petered out around here.
14. loop-AES Update
28 Jul (1 post) Archive Link: "Announce loop-AES-v2.1c file/swap crypto
package"
People: Jari Ruusu, Russell King
Jari Ruusu announced a new version of loop-AES, saying:
loop-AES changes since previous release:
+ Adapted and merged Russell King's loop.c flush_dcache_page() fix. Most
sane processors were not affected, but some processors with goofy
aliasing caches were indeed affected (2.4 and 2.6 kernels).
+ Added optimized assembler implementations of AES and MD5 functions for
AMD64 and compatible processors.
+ Pentium-2 optimized assembler implementations of AES and MD5 are really
i386 compatible, so now those assembler implementations are enabled for
all x86 processors.
+ Fixed Makefile to be compatible with distros that include "" characters
in KERNELRELEASE string.
+ Added dkms.conf configuration file for Dynamic Kernel Module Support.
Charles Duffy wrote original version.
+ Added support for /lib/modules/`uname -r`/source symlink.
+ Converted MODULE_PARM macros to module_param (2.6 kernels only).
+ Added workaround for scripts/modpost breakage (2.6 kernels only).
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.1c.tar.bz2
md5sum b404d9d679b7096dd3fb089345c52320
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.1c.tar.bz2.sign
Additional ciphers package changes since previous release:
+ Fixed Makefile to be compatible with distros that include "" characters
in KERNELRELEASE string.
+ Added dkms.conf configuration file for Dynamic Kernel Module Support.
Adapted from version that was originally written by Charles Duffy.
+ Added support for /lib/modules/`uname -r`/source symlink.
+ Added workaround for scripts/modpost breakage (2.6 kernels only).
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/ciphers/ciphers-v2.0i.tar.bz2
md5sum 1a5e1d967bca0cde71a32e533ef26ce9
http://loop-aes.sourceforge.net/ciphers/ciphers-v2.0i.tar.bz2.sign
15. PPC8xx Maintainership
29 Jul (1 post) Archive Link: "PPC8xx Maintainer patch"
Topics: MAINTAINERS File
People: Paul Mackerras, Tom Rini
Paul Mackerras posted a patch to the MAINTAINERS file, listing Tom Rini as the
official maintainer of Linux for PowerPC embedded PPC8xx and the PowerPC boot
code.
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.