A large number of patches have already been merged and will show up in the
first 2.6.10 prepatch. Some of those have been covered on this page
before, but others have not. As a way of catching up with current events,
we'll take a quick look at a few of these patches.
The completely fair queueing (CFQ) I/O scheduler endeavors to get good
performance from block devices while dividing the available bandwidth
equally between the processes contending for each device. 2.6.10 will
contain a major rework of the CFQ scheduler, called "CFQ v2." Some of
the changes in this version are:
- Process I/O context information is maintained for the lifetime of each
process, rather than just for the periods when the process has
outstanding I/O. This change fixes some starvation scenarios which
came up with CFQ v1.
- Grouping of processes can be done by user ID, group ID, thread group,
or process group; the policy in force can be changed at runtime.
- Request ordering is more strictly enforced as a way of limiting the
maximum latency experienced by any given request.
- Small backward seeks are occasionally allowed if they look like they
will improve responsiveness.
The code is also more heavily commented; author Jens Axboe says that was
done to increase its AAF - "akpm acceptance factor." AKPM is Andrew
Morton, who has been known to complain about insufficiently commented
Simple circular buffers
Circular buffers are a common data structure in the kernel, but there has
never been a generic implementation available for use. Stelian Pop decided
to change that; he was almost certainly surprised, however, by the large number of
iterations it took to respond to all the comments he got. In the end, this
effort showed the value of having a single, generic implementation in the
kernel. Even a data structure as simple as a circular buffer can be tricky
to implement correctly; it makes no sense for every developer to go through
that process each time a new one is needed. With a single, well-reviewed
implementation, the chances of it being truly correct are much better.
A circular buffer is represented by struct kfifo, defined in
<linux/kfifo.h>. A staticly-allocated buffer can be
initialized with kfifo_init(), or allocation and initialization
can be performed together with kfifo_alloc():
struct kfifo *kfifo_init(unsigned char *buffer, unsigned int size,
int gfp_mask, spinlock_t *lock);
struct kfifo *kfifo_alloc(unsigned int size, int gfp_mask,
Either way, size is the desired size of the buffer (in bytes, must
be a power of two), gfp_mask is a set of GFP_ flags
controlling how memory allocations will be performed, and lock is
a spinlock which will be used to serialize access to the data structure.
The functions for moving data into and out of the buffer are:
unsigned int kfifo_put(struct kfifo *fifo, unsigned char *buffer,
unsigned int len);
unsigned int kfifo_get(struct kfifo *fifo, unsigned char *buffer,
unsigned int len);
These functions move at most len bytes between the structure and
buffer; the actual number of bytes transferred is returned. The
number of bytes currently stored in a circular buffer can be obtained by
passing it to kfifo_len(), and a buffer may be flushed by passing
it to kfifo_reset(). A dynamically-allocated buffer may be
returned to the system with kfifo_free(); there does not seem to
be a way to free memory from staticly-allocated buffers.
The kernel events notification mechanism has been covered here a couple of
times. This code provides a way for user-space processes to learn about
important events by way of a netlink socket. The final form of the event
generation interface (for now) is:
int kobject_uevent(struct kobject *kobj, enum kobject_action action,
struct attribute *attr);
The kobject describes where the interesting event happened. For the one
explicit use currently in the kernel (filesystem mount and unmount events),
the kobject corresponds to the disk partition involved. action is
a small set of possible events; it is currently one of KOBJ_ADD,
KOBJ_REMOVE, KOBJ_CHANGE, KOBJ_MOUNT, and
KOBJ_UMOUNT. The "add" and "remove" actions are generated along
with hotplug events; "change" describes attribute value changes, and
"mount" and "unmount" are for filesystem events. The final parameter
(attr) is an optional attribute of the given kobject which
provides further information.
The patches merged also modify how hotplug events are handled; such events
now are reported in two ways: via the new events mechanism and through an
invocation of /sbin/hotplug.
to post comments)