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.6pre5aa1
Date: Thu, 21 Jun 2001 20:46:18 +0200	[thread overview]
Message-ID: <20010621204618.C707@athlon.random> (raw)

Diff between 2.4.6pre3aa2 and 2.4.6pre5aa1:

-------------------------------------------------------------
	Moved on top of 2.4.6pre5.

Only in 2.4.6pre3aa2: 00_alpha-warnings-1
Only in 2.4.6pre3aa2: 00_backout-udelay-1
Only in 2.4.6pre3aa2: 00_locks-1
Only in 2.4.6pre3aa2: 00_xircom-tulip-cb-2.4.5ac13-1
Only in 2.4.6pre3aa2: 10_alpha-udelay-1

	Merged in pre5.

Only in 2.4.6pre5aa1: 00_alpha-irq_err_count-1

	Fix alpha compile from Jeff.

	(recommended)

Only in 2.4.6pre5aa1: 00_bh-async-1

	Patch to Stefan.Bader@de.ibm.com to allow lowlevel layer
	to override bh->b_end_io callback without breaking the
	async I/O.

	(nice to have)

Only in 2.4.6pre3aa2: 00_ksoftirqd-6
Only in 2.4.6pre5aa1: 00_ksoftirqd-7

	%c1 do_softirq merged in mainline, fix reject.

Only in 2.4.6pre3aa2: 00_ksoftirqd-6_ppc-1
Only in 2.4.6pre5aa1: 00_ksoftirqd-7_ppc-2

	Dropped a comment (no code change). ('and' is really needed
	because lwz doesn't update the equal bit state of the cpu)

Only in 2.4.6pre3aa2: 10_no-virtual-1
Only in 2.4.6pre5aa1: 10_no-virtual-2

	Comments generated rejects, fixup.

Only in 2.4.6pre3aa2/30_tux: 30_tux-2
Only in 2.4.6pre5aa1/30_tux: 30_tux-3

	Include init.h to fix some compilation trouble and drop the
	__KERNEL_SYSCALLS__ #defines from the .c files.
-------------------------------------------------------------

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1.bz2
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/30_tux/
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/40_experimental/

In the 40_experimental there's the latest blkdev in pagecache and it has
to be applied after all the other patches. Issue to solve in the
blkdev-pagecache-3 patch are:

-	fix ramdisk: lookup on pagecache and pin blkdev address space
	while the ramdisk stays allocated
-	I/O granularity is fixed to 4k, this can be easily decreased with
	a recompile, but I'm wondering if we should make the granularity
	dynamic somehow to avoid the partial write to do too many
	read-modify-write cycles
-	Currently the pagecache assumes the end of the device is aligned
	for excess on the next 4k (in genereal BUFFERED_BLOCKSIZE)
	boundary to be sure we can read and write all bytes of the disk.
	(see buffered_blk_size) I don't expect problems but blkdev layer
	must be able to cope with it.

I'm running this patch on all my systems and I didn't had problems yet
(though you cannot expect to get ramdisk and in turn initrd working
[ramfs works fine of course]). As said in a earlier email you can do
rawio now by simply openeing the blkdev with O_DIRECT (however you get
the BUFFERED_BLOCKSIZE granularity for it too, instead of the
hardblocksize granularity of the /dev/raw rawio, but this also means you
pay less cycles for bulding a flood of 512 bytes large bh) and mmap
private and shared on the blkdev works like with files in the fs.

Andrea

                 reply	other threads:[~2001-06-21 18:46 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=20010621204618.C707@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.