2.4.10pre4aa1

Andrea Arcangeli (andrea@suse.de)
Mon, 3 Sep 2001 03:17:25 +0200


Only in 2.4.10pre2aa3: 00_elf-at_phdr-1
Only in 2.4.10pre2aa3: 00_raid1-prealloc-1
Only in 2.4.10pre2aa3: 00_smp_build-irq-1

Now part of mainline.

Only in 2.4.10pre2aa3: 00_km_user-1
Only in 2.4.10pre4aa1: 00_km_user-2
Only in 2.4.10pre2aa3: 00_numa-sched-6
Only in 2.4.10pre4aa1: 00_numa-sched-7

Rediffed due trivial rejects.

Only in 2.4.10pre2aa3: 00_o_direct-14
Only in 2.4.10pre4aa1: 00_o_direct-15

Avoid running f_ops->open in case the user opened the file with
O_DIRECT and the iobuf preallocation failed due OOM.

Only in 2.4.10pre4aa1: 10_rawio-f_iobuf-1

Implemented the rawio optimization for the simultaneous I/O to the same
rawio device. It depends on the O_DIRECT f_iobuf* support to avoid
allocation of kiobufs in the read/write fast paths. (see the thread
'changes to kiobuf support in 2.4.(?)4' on l-k on date 1 Aug 2001 for
the details on the design)

Two things to keep in mind: 1) open("/dev/raw*") [like open(O_DIRECT)]
is still costly, 2) simultaneous I/O from different filedescriptors
pointing to the same file are still costly as well (you must reopen
the raw device if you don't want to run into the kiobuf allocation
flood).

Next step is to split the kiobuf in kiobuf and kiobuf_io to avoid
allocating the I/O ram backend for the non-IO users of the kiobufs.
Then probably we can re-slabify the kiobuf. This step is much lower
prio though (the showstopper was the rawio read/write fast paths that
are just fixed by now).

Only in 2.4.10pre2aa3: 50_uml-patch-2.4.9-2.bz2
Only in 2.4.10pre4aa1: 50_uml-patch-2.4.9-3.bz2

Picked last update from sourceforge.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/