All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: linux-kernel@vger.kernel.org
Subject: 2.4.7pre5aa1
Date: Wed, 11 Jul 2001 02:45:06 +0200	[thread overview]
Message-ID: <20010711024506.B685@athlon.random> (raw)

Diff between 2.4.7pre3aa1 and 2.4.7pre5aa1:

Only in 2.4.7pre3aa1: 00_async-io-unlock-race-1
Only in 2.4.7pre3aa1: 00_cpus_allowed-1

	Merged in mainline.

Only in 2.4.7pre3aa1: 00_bh-async-1
Only in 2.4.7pre5aa1: 00_bh-async-2

	Rediffed against pre5 due trivial rejects.

Only in 2.4.7pre5aa1: 00_create_bounces-sleeps-1

	Kill KM_BOUNCE_WRITE and use kmap instead of kmap_atomic+cli in the
	write-bounce case since create_bounces is allowed to sleep.

Only in 2.4.7pre5aa1: 00_drop___unlock_buffer-1

	Rename __unlock_buffer to unlock_buffer. I did it before knowing Linus
	did it too sorry.

Only in 2.4.7pre5aa1: 00_drop_async-io-get_bh-1

	Drop the get_bh/atomic_inc around the async I/O, for any bh that uses
	set_buffer_async_io the page will be locked for the whole duration of
	the I/O (that's why you use set_buffer_async_io in first place) so the
	bh doesn't need the additional b_count protection during the I/O and we
	this way we can save some cycle.

Only in 2.4.7pre5aa1: 00_drop_end_buffer_write-1

	Drop end_buffer_write and replace with the sync_io callback to avoid
	wasting icache. Here too I should have waited for pre6 but I just
	did it.

Only in 2.4.7pre5aa1: 00_drop_write_unlocked-get_bh-1

	Micro-optimize a bit in write_unlocked_buffers: the get_bh is needed
	only if the buffer was dirty and we are going to do the I/O on it (all
	the rest is protected by the lru_list_lock).

Only in 2.4.7pre5aa1: 00_kiobuf-backout-get_bh-1

	Remove the get_bh/put_bh around the kiobuf driven I/O, the notifion of
	the refernece count and of I/O in flight belongs to the kiobuf not to
	the bh, the bh are just an array of ram in the kiobuf, and this way we
	save some cycle.

Only in 2.4.7pre3aa1: 00_ksoftirqd-7_ppc-2
Only in 2.4.7pre3aa1: 00_ksoftirqd-8

	ksoftirqd is in mainline. All ports needs to synchronize now.
	Alpha and x86 are uptodate in pre5. I uptodate uml in my tree
	to get it right too.

	For port maintainers: in short you need to do the:

		if (pending_softirq(cpu))
			do_softirq();

	check only when returning from irqs that can post softirq events (for
	example IPI never post softirq events currently, theoretically you
	could with the smp_call but nobody uses it that way at the moment). For
	example x86 and alpha do the check in C in the last few lines of C of
	the irq handler.

	You _don't_ need to check for pending softirq when returning
	from kernel to userspace any longer, that case is now handled with
	ksoftirqd, this gives higher performance in the ret-to-userspace and
	reschedule fast paths (that is the change made by Linus).

	As usual ksoftirqd keeps handling the overflow case.

Only in 2.4.7pre5aa1: 00_linus-brelse-fix-1

	This is a patch from Linus to fix a race condition he spotted in brelse
	that could trigger on architectures where the atomic_t changes don't
	imply SMP memory barriers at the CPU level.

Only in 2.4.7pre3aa1: 00_meminfo-wraparound-1
Only in 2.4.7pre5aa1: 00_meminfo-wraparound-2

	Rediffed to fixup trivial rejects.

Only in 2.4.7pre3aa1: 00_msync-fb0-1

	Merged in mainline.

Only in 2.4.7pre5aa1: 00_o_direct-10
Only in 2.4.7pre3aa1: 00_o_direct-9

	Fixed O_SYNC|O_DIRECT, when O_SYNC was used in combination with
	O_DIRECT it was returning a short write even if all the I/O was
	reaching the disk succesfully and the f_pos was updated correctly, (in
	my regression testing of O_SYNC|O_DIRECT I obviously forgotten to check
	for short writes, I was only checking for errors and it was working
	like a charm). Thanks to Peter for spotting and reporting this.

	Fixed also another bug that could forget to wait for I/O completion
	of async I/O for O_SYNC/fsync/fdatasync.

Only in 2.4.7pre3aa1: 51_uml-ac-to-aa-1.bz2
Only in 2.4.7pre5aa1: 51_uml-ac-to-aa-2.bz2

	Updated to pre5 ksoftirqd logic.

Available at:

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.7pre5aa1/
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.7pre5aa1.bz2

A fixed O_DIRECT patch against vanilla 2.4.7pre5 is here:

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.7pre5/o_direct-10

Andrea

                 reply	other threads:[~2001-07-11  0:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010711024506.B685@athlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.