This should fix the last loop deadlocks under VM pressure, if not please
let me know.
I didn't fixed the ia64 compilation troubles, but it should be very easy
to fix if anybody needs.
URL:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.17rc2aa1.bz2
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.17rc2aa1/
Only in 2.4.17rc1aa1: 00_loop-deadlock-1
Merged in mainline.
Only in 2.4.17rc2aa1: 00_pgt-cache-leak-1
Avoid potentially leaking pagetables into the per-cpu queues.
Only in 2.4.17rc2aa1: 00_x86-fast-pte-1
Reenable the pagetable per-cpu queues on x86 that I found to be
disabled during 2.4.17pre.
Only in 2.4.17rc1aa1: 10_vm-20
Only in 2.4.17rc2aa1: 10_vm-21
Drop some leftover and rediffed.
Only in 2.4.17rc1aa1: 60_tux-2.4.16-final-D5.bz2
Only in 2.4.17rc2aa1: 60_tux-2.4.16-final-D6.bz2
Latest update from Ingo at http://www.redhat.com/~mingo/ .
Only in 2.4.17rc2aa1: 70_loop-deadlock-2
Previous fix cured balance_dirty(), this one will cure
the memory balancing, to avoid reentrant I/O in the loop
thread.
Andrea
> This should fix the last loop deadlocks under VM pressure, if not please
> let me know.
>
Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
soon as I boot into that kernel again (probably later tonight).
On Wed, Dec 19, 2001 at 09:32:12PM +0100, Gergely Nagy wrote:
> > This should fix the last loop deadlocks under VM pressure, if not please
> > let me know.
> >
>
> Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
> soon as I boot into that kernel again (probably later tonight).
perfect, thanks.
Andrea
The output of ksymoops, and some other miscellaneous information is
attached, as I promised.
The box is an AMD K6-300, with 64Mb memory, and around 130Mb swap
(from which ~110Mb was free, there was no VM pressure). It is running
Debian unstable.
What I did was to boot into my system as usual, then stop all
processes I didn't need. After that, I did a `touch /tmp/foo', then a
`sync'. /tmp is /var/cache/ext3test, despite the filename, it is ext2,
mounted from an ext3 partition (/) (see the output of mount below).
`sync' hung, and the load started to slowly increase, shortly before I
rebooted, it was almost at 3:
12:02:26 up 6 min, 2 users, load average: 2.97, 1.81, 0.78
(btw, before doing the `sync', the load was 0.99; with 2.4.14, my
usual load is between 0.20-0.50)
,----[ mount ]
| /dev/hda3 on / type ext3 (rw)
| proc on /proc type proc (rw)
| /dev/hda1 on /boot type ext2 (rw)
| /dev/hdd2 on /gnu type ext2 (rw)
| /dev/hdd1 on /gnu/mnt type ext2 (rw)
| /dev/hda6 on /gnu/work type ext3 (rw)
| /usr/bin/emacs on /bin/emacs type none (rw,bind)
| /gnu/work/cache-apt/archives on /var/cache/apt/archives type none (rw,bind)
| /gnu/work/lib-apt/lists on /var/lib/apt/lists type none (rw,bind)
| /gnu/work/cache-apt/archives on /chroot/base/var/cache/apt/archives type none (rw,bind)
| /gnu/work/lib-apt/lists on /chroot/base/var/lib/apt/lists type none (rw,bind)
| /var/cache/ext3test on /chroot/base/tmp type ext2 (rw,loop=/dev/loop0)
| devfs on /chroot/base/dev type devfs (rw)
| proc on /chroot/base/proc type proc (rw)
`----
On Wed, Dec 19, 2001 at 09:52:08PM +0100, Andrea Arcangeli wrote:
> On Wed, Dec 19, 2001 at 09:32:12PM +0100, Gergely Nagy wrote:
> > > This should fix the last loop deadlocks under VM pressure, if not please
> > > let me know.
> > >
> >
> > Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
> > soon as I boot into that kernel again (probably later tonight).
>
> perfect, thanks.
My desktop running rc2aa1 crashed in lo_send a few minutes ago while
testing oom conditions with simultaneous heavy I/O to the loop device,
so I had a chance to fix another bug. Maybe this is what you
experienced, but I also got an oops (maybe you didn't seen the oops
because the machine hanged up?). Just guessing.
Anyways here the fix (untested as usual :)
--- 2.4.17rc2aa1/fs/buffer.c.~1~ Wed Dec 19 03:43:24 2001
+++ 2.4.17rc2aa1/fs/buffer.c Thu Dec 20 19:02:02 2001
@@ -2337,7 +2337,7 @@
struct buffer_head *bh;
page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
- if (IS_ERR(page))
+ if (!page)
return NULL;
if (!PageLocked(page))
--- 2.4.17rc2aa1/mm/filemap.c.~1~ Wed Dec 19 03:43:23 2001
+++ 2.4.17rc2aa1/mm/filemap.c Thu Dec 20 19:01:53 2001
@@ -942,7 +942,7 @@
spin_unlock(&pagecache_lock);
if (!page) {
struct page *newpage = alloc_page(gfp_mask);
- page = ERR_PTR(-ENOMEM);
+ page = NULL;
if (newpage) {
spin_lock(&pagecache_lock);
page = __find_lock_page_helper(mapping, index, *hash);
explanation: grab_cache_page must definitely return NULL in case of oom,
that's the API used by the callers. find_or_create_page can use the same
API as well (there's no point for the ERR_PTR(-ENOMEM) complication).
Andrea
On Thu, 20 Dec 2001, Andrea Arcangeli wrote:
> Anyways here the fix (untested as usual :)
>
> --- 2.4.17rc2aa1/fs/buffer.c.~1~ Wed Dec 19 03:43:24 2001
> +++ 2.4.17rc2aa1/fs/buffer.c Thu Dec 20 19:02:02 2001
> @@ -2337,7 +2337,7 @@
> struct buffer_head *bh;
>
> page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
> - if (IS_ERR(page))
> + if (!page)
Isn't this in 2.4.17 already? Marcelo, please check.
> +++ 2.4.17rc2aa1/mm/filemap.c Thu Dec 20 19:01:53 2001
> @@ -942,7 +942,7 @@
> spin_unlock(&pagecache_lock);
> if (!page) {
> struct page *newpage = alloc_page(gfp_mask);
> - page = ERR_PTR(-ENOMEM);
> + page = NULL;
Don't be silly, just remove the line (page _is_ NULL already, we just
checked).
Linus
On Thu, Dec 20, 2001 at 10:27:37AM -0800, Linus Torvalds wrote:
>
> On Thu, 20 Dec 2001, Andrea Arcangeli wrote:
> > Anyways here the fix (untested as usual :)
> >
> > --- 2.4.17rc2aa1/fs/buffer.c.~1~ Wed Dec 19 03:43:24 2001
> > +++ 2.4.17rc2aa1/fs/buffer.c Thu Dec 20 19:02:02 2001
> > @@ -2337,7 +2337,7 @@
> > struct buffer_head *bh;
> >
> > page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
> > - if (IS_ERR(page))
> > + if (!page)
>
> Isn't this in 2.4.17 already? Marcelo, please check.
it isn't in 2.4.17-rc2.
>
> > +++ 2.4.17rc2aa1/mm/filemap.c Thu Dec 20 19:01:53 2001
> > @@ -942,7 +942,7 @@
> > spin_unlock(&pagecache_lock);
> > if (!page) {
> > struct page *newpage = alloc_page(gfp_mask);
> > - page = ERR_PTR(-ENOMEM);
> > + page = NULL;
>
> Don't be silly, just remove the line (page _is_ NULL already, we just
> checked).
indeed (compiler could optimize it away but nicer code to delete it).
Andrea
On Thu, 20 Dec 2001, Andrea Arcangeli wrote:
> >
> > Isn't this in 2.4.17 already? Marcelo, please check.
>
> it isn't in 2.4.17-rc2.
Ok, it _is_ in 2.5.x, so I guess this was a fix that I didn't point
Marcelo to well enough..
Linus
Hi Linus,
In article <[email protected]> you wrote:
> Ok, it _is_ in 2.5.x, so I guess this was a fix that I didn't point
> Marcelo to well enough..
I was a bad interaction between Marcelo and me - I send him the incomplete
patch first and then the old one. It seems like he apllied the first one
and I didn't check which one went in :P
> Not sure what's going on with the i_sem, are you playing with the loopfile
> somehow during the sync?
No. It's sitting in /var/cache/ext3test, and nothing else touches it.
> Can you also try to find more info about c01efe72
> <stext_lock+ee2/273a> with an objdump -j .text.lock? (should be the
> slow path of down() corresponding to the i_sem down in lo_send)
I guess I'm a bit uneducated, but objdump -j .text.lock vmlinux
doesn't work here, I'm obviously doing something wrong.
> are you sure it's really related to the loop device? (and not a
> ""genuine"" IDE lockup or something like that)
Yes, I'm sure. Without using the loop device, the system works fine,
as far as I can tell, and even with the loop device, 2.4.14 is OK.
I booted into 2.4.17-rc2aa1(compiled w/ gcc-3.0.3), and after an hour of
uptime or so, was unable to read anything in /proc (top locked, procinfo, and
I couldn't kill them b/c killall and pidof would lock as well)
I made only one mod. I changed HZ to 1024, but I don't think that should have
done it.
I figure either a problem in gcc 3.0.3, or a kernel bug.
Ideas?
---
tabris