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.