From:	 Andrea Arcangeli <andrea@suse.de>
To:	 linux-kernel@vger.kernel.org
Subject: 2.4.10pre4aa1
Date:	 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/