Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
newsfeed.gamma.ru!Gamma.RU!news.tele.dk!small.news.tele.dk!129.240.148.23!
uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Sun, 16 Sep 2001 15:00:17 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
To: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Linux-2.4.10-pre10
Original-Message-ID: <Pine.LNX.4.33.0109161454090.3392-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sun, 16 Sep 2001 22:02:59 GMT
Message-ID: <fa.o9qhfnv.g466rc@ifi.uio.no>
Lines: 143
Changelog appended..
Most of the patches are due to the continuing merge with Alan, others tend
to be fairly small.
However, I'd love for VM people to look at the page reference bit cleanups
- I might have missed some place that needs to mark something referenced,
but I also know I fixed a few places that hadn't done it right before.
For example, the old code did not react very well to read-ahead: it would
mark a page referenced on the first real access, if that page had earlier
been read in through read-ahead. In contrast, if it was _not_ read in with
read-ahead (ie the first page of a file, for example), it would not mark
the page referenced until the _second_ real access. Which just gives you
an idea of how truly random the aging used to be.
The new (simpler) code should be a lot less random. But it will probably
need a few tweaks. It would be very interesting to hear about specific
loads that show problems (or loads that are good, of course).
Linus
-----
pre10:
- Alan Cox: continued merging
- Mingming Cao: make msgrcv/shmat check the queue/segment ID's properly
- Greg KH: USB serial init failure fix, Xircom serial converter driver
- Neil Brown: nsfd/raid/md/lockd cleanups
- Ingo Molnar: multipath RAID personality, raid xor update
- Hugh Dickins/Marcelo Tosatti: swapin read-ahead race fix
- Vojtech Pavlik: fix up some of the infrastructure for x86-64
- Robert Love: AMD 761 AGP GART support
- Jens Axboe: fix SCSI-generic queue handling race
- me: be sane about page reference bits
pre9:
- Greg KH: start migration to new "min()/max()"
- Roman Zippel: move affs over to "min()/max()".
- Vojtech Pavlik: VIA update (make sure not to IRQ-unmask a vt82c576)
- Jan Kara: quota bug-fix (don't decrement quota for non-counted inode)
- Anton Altaparmakov: more NTFS updates
- Al Viro: make nosuid/noexec/nodev be per-mount flags, not per-filesystem
- Alan Cox: merge input/joystick layer differences, driver and alpha merge
- Keith Owens: scsi Makefile cleanup
- Trond Myklebust: fix oopsable race in locking code
- Jean Tourrilhes: IrDA update
pre8:
- Christoph Hellwig: clean up personality handling a bit
- Robert Love: update sysctl/vm documentation
- make the three-argument (that everybody hates) "min()" be "min_t()",
and introduce a type-anal "min()" that complains about arguments of
different types.
pre7:
- Alan Cox: big driver/mips sync
- Andries Brouwer, Christoph Hellwig: more gendisk fixups
- Tobias Ringstrom: tulip driver workaround for DC21143 erratum
pre6:
- Jens Axboe: remove trivially dead io_request_lock usage
- Andrea Arcangeli: softirq cleanup and ARM fixes. Slab cleanups
- Christoph Hellwig: gendisk handling helper functions/cleanups
- Nikita Danilov: reiserfs dead code pruning
- Anton Altaparmakov: NTFS update to 1.1.18
- firestream network driver: patch reverted on authors request
- NIIBE Yutaka: SH architecture update
- Paul Mackerras: PPC cleanups, PPC8xx update.
- me: reverse broken bootdata allocation patch that went into pre5
pre5:
- Merge with Alan
- Trond Myklebust: NFS fixes - kmap and root inode special case
- Al Viro: more superblock cleanups, inode leak in rd.c, minix
directories in page cache
- Paul Mackerras: clean up rubbish from sl82c105.c
- Neil Brown: md/raid cleanups, NFS filehandles
- Johannes Erdfelt: USB update (usb-2.0 support, visor fix, Clie fix,
pl2303 driver update)
- David Miller: sparc and net update
- Eric Biederman: simplify and correct bootdata allocation - don't
overwrite ramdisks
- Tim Waugh: support multiple SuperIO devices, parport doc updates
pre4:
- Hugh Dickins: swapoff cleanups and speedups
- Matthew Dharm: USB storage update
- Keith Owens: Makefile fixes
- Tom Rini: MPC8xx build fix
- Nikita Danilov: reiserfs update
- Jakub Jelinek: ELF loader fix for ET_DYN
- Andrew Morton: reparent_to_init() for kernel threads
- Christoph Hellwig: VxFS and SysV updates, vfs_permission fix
pre3:
- Johannes Erdfelt, Oliver Neukum: USB printer driver race fix
- John Byrne: fix stupid i386-SMP irq stack layout bug
- Andreas Bombe, me: yenta IO window fix
- Neil Brown: raid1 buffer state fix
- David Miller, Paul Mackerras: fix up sparc and ppc respectively for kmap/kbd_rate
- Matija Nalis: umsdos fixes, and make it possible to boot up with umsdos
- Francois Romieu: fix bugs in dscc4 driver
- Andy Grover: new PCI config space access functions (eventually for ACPI)
- Albert Cranford: fix incorrect e2fsprog data from ver_linux script
- Dave Jones: re-sync x86 setup code, fix macsonic kmalloc use
- Johannes Erdfelt: remove obsolete plusb USB driver
- Andries Brouwer: fix USB compact flash version info, add blksize ioctls
pre2:
- Al Viro: block device cleanups
- Marcelo Tosatti: make bounce buffer allocations more robust (it's ok
for them to do IO, just not cause recursive bounce IO. So allow them)
- Anton Altaparmakov: NTFS update (1.1.17)
- Paul Mackerras: PPC update (big re-org)
- Petko Manolov: USB pegasus driver fixes
- David Miller: networking and sparc updates
- Trond Myklebust: Export atomic_dec_and_lock
- OGAWA Hirofumi: find and fix umsdos "filldir" users that were broken
by the 64-bit-cleanups. Fix msdos warnings.
- Al Viro: superblock handling cleanups and race fixes
- Johannes Erdfelt++: USB updates
pre1:
- Jeff Hartmann: DRM AGP/alpha cleanups
- Ben LaHaise: highmem user pagecopy/clear optimization
- Vojtech Pavlik: VIA IDE driver update
- Herbert Xu: make cramfs work with HIGHMEM pages
- David Fennell: awe32 ram size detection improvement
- Istvan Varadi: umsdos EMD filename bug fix
- Keith Owens: make min/max work for pointers too
- Jan Kara: quota initialization fix
- Brad Hards: Kaweth USB driver update (enable, and fix endianness)
- Ralf Baechle: MIPS updates
- David Gibson: airport driver update
- Rogier Wolff: firestream ATM driver multi-phy support
- Daniel Phillips: swap read page referenced set - avoid swap thrashing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Mon, 17 Sep 2001 17:08:37 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
To: Kernel Mailing List <linux-ker...@vger.kernel.org>
cc: Andrea Arcangeli <and...@suse.de>
Subject: Linux 2.4.10-pre11
Original-Message-ID: <Pine.LNX.4.33.0109171608310.1108-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 00:12:48 GMT
Message-ID: <fa.oaa1c7v.gkm5rb@ifi.uio.no>
Lines: 149
Ok, the big thing here is continued merging, this time with Andrea.
I still don't like some of the VM changes, but integrating Andrea's VM
changes results in (a) better performance and (b) much cleaner inactive
page handling in particular. Besides, for the 2.4.x tree, the big priority
is stability, we can re-address my other concerns during 2.5.x.
This also merges the blkdev in page cache patch, and that will hopefully
make it noticeably easier to do the "do bread() with page cache too", at
which point a lot of the current ugly synchronization issues will go away.
Oh, and it gets the direct-IO improvements from Andrea too.
[ Other small patches from Andrea merged just to make future merges
easier. ]
The console locking merge with Andrew Morton also moves us a bit closer to
the -ac tree..
Full 2.4.10 ChangeLog appended.
Linus
------
pre11:
- Neil Brown: md cleanups/fixes
- Andrew Morton: console locking merge
- Andrea Arkangeli: major VM merge
pre10:
- Alan Cox: continued merging
- Mingming Cao: make msgrcv/shmat check the queue/segment ID's properly
- Greg KH: USB serial init failure fix, Xircom serial converter driver
- Neil Brown: nsfd/raid/md/lockd cleanups
- Ingo Molnar: multipath RAID personality, raid xor update
- Hugh Dickins/Marcelo Tosatti: swapin read-ahead race fix
- Vojtech Pavlik: fix up some of the infrastructure for x86-64
- Robert Love: AMD 761 AGP GART support
- Jens Axboe: fix SCSI-generic queue handling race
- me: be sane about page reference bits
pre9:
- Greg KH: start migration to new "min()/max()"
- Roman Zippel: move affs over to "min()/max()".
- Vojtech Pavlik: VIA update (make sure not to IRQ-unmask a vt82c576)
- Jan Kara: quota bug-fix (don't decrement quota for non-counted inode)
- Anton Altaparmakov: more NTFS updates
- Al Viro: make nosuid/noexec/nodev be per-mount flags, not per-filesystem
- Alan Cox: merge input/joystick layer differences, driver and alpha merge
- Keith Owens: scsi Makefile cleanup
- Trond Myklebust: fix oopsable race in locking code
- Jean Tourrilhes: IrDA update
pre8:
- Christoph Hellwig: clean up personality handling a bit
- Robert Love: update sysctl/vm documentation
- make the three-argument (that everybody hates) "min()" be "min_t()",
and introduce a type-anal "min()" that complains about arguments of
different types.
pre7:
- Alan Cox: big driver/mips sync
- Andries Brouwer, Christoph Hellwig: more gendisk fixups
- Tobias Ringstrom: tulip driver workaround for DC21143 erratum
pre6:
- Jens Axboe: remove trivially dead io_request_lock usage
- Andrea Arcangeli: softirq cleanup and ARM fixes. Slab cleanups
- Christoph Hellwig: gendisk handling helper functions/cleanups
- Nikita Danilov: reiserfs dead code pruning
- Anton Altaparmakov: NTFS update to 1.1.18
- firestream network driver: patch reverted on authors request
- NIIBE Yutaka: SH architecture update
- Paul Mackerras: PPC cleanups, PPC8xx update.
- me: reverse broken bootdata allocation patch that went into pre5
pre5:
- Merge with Alan
- Trond Myklebust: NFS fixes - kmap and root inode special case
- Al Viro: more superblock cleanups, inode leak in rd.c, minix
directories in page cache
- Paul Mackerras: clean up rubbish from sl82c105.c
- Neil Brown: md/raid cleanups, NFS filehandles
- Johannes Erdfelt: USB update (usb-2.0 support, visor fix, Clie fix,
pl2303 driver update)
- David Miller: sparc and net update
- Eric Biederman: simplify and correct bootdata allocation - don't
overwrite ramdisks
- Tim Waugh: support multiple SuperIO devices, parport doc updates
pre4:
- Hugh Dickins: swapoff cleanups and speedups
- Matthew Dharm: USB storage update
- Keith Owens: Makefile fixes
- Tom Rini: MPC8xx build fix
- Nikita Danilov: reiserfs update
- Jakub Jelinek: ELF loader fix for ET_DYN
- Andrew Morton: reparent_to_init() for kernel threads
- Christoph Hellwig: VxFS and SysV updates, vfs_permission fix
pre3:
- Johannes Erdfelt, Oliver Neukum: USB printer driver race fix
- John Byrne: fix stupid i386-SMP irq stack layout bug
- Andreas Bombe, me: yenta IO window fix
- Neil Brown: raid1 buffer state fix
- David Miller, Paul Mackerras: fix up sparc and ppc respectively for kmap/kbd_rate
- Matija Nalis: umsdos fixes, and make it possible to boot up with umsdos
- Francois Romieu: fix bugs in dscc4 driver
- Andy Grover: new PCI config space access functions (eventually for ACPI)
- Albert Cranford: fix incorrect e2fsprog data from ver_linux script
- Dave Jones: re-sync x86 setup code, fix macsonic kmalloc use
- Johannes Erdfelt: remove obsolete plusb USB driver
- Andries Brouwer: fix USB compact flash version info, add blksize ioctls
pre2:
- Al Viro: block device cleanups
- Marcelo Tosatti: make bounce buffer allocations more robust (it's ok
for them to do IO, just not cause recursive bounce IO. So allow them)
- Anton Altaparmakov: NTFS update (1.1.17)
- Paul Mackerras: PPC update (big re-org)
- Petko Manolov: USB pegasus driver fixes
- David Miller: networking and sparc updates
- Trond Myklebust: Export atomic_dec_and_lock
- OGAWA Hirofumi: find and fix umsdos "filldir" users that were broken
by the 64-bit-cleanups. Fix msdos warnings.
- Al Viro: superblock handling cleanups and race fixes
- Johannes Erdfelt++: USB updates
pre1:
- Jeff Hartmann: DRM AGP/alpha cleanups
- Ben LaHaise: highmem user pagecopy/clear optimization
- Vojtech Pavlik: VIA IDE driver update
- Herbert Xu: make cramfs work with HIGHMEM pages
- David Fennell: awe32 ram size detection improvement
- Istvan Varadi: umsdos EMD filename bug fix
- Keith Owens: make min/max work for pointers too
- Jan Kara: quota initialization fix
- Brad Hards: Kaweth USB driver update (enable, and fix endianness)
- Ralf Baechle: MIPS updates
- David Gibson: airport driver update
- Rogier Wolff: firestream ATM driver multi-phy support
- Daniel Phillips: swap read page referenced set - avoid swap thrashing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Mon, 17 Sep 2001 20:17:18 -0300 (BRT)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: marc...@freak.distro.conectiva
To: Linus Torvalds <torva...@transmeta.com>
Cc: Kernel Mailing List <linux-ker...@vger.kernel.org>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.33.0109171608310.1108-100000@penguin.transmeta.com>
Original-Message-ID: <Pine.LNX.4.21.0109172016200.6823-100000@freak.distro.conectiva>
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 00:49:50 GMT
Message-ID: <fa.nqvrm6v.s284rt@ifi.uio.no>
References: <fa.oaa1c7v.gkm5rb@ifi.uio.no>
Lines: 28
On Mon, 17 Sep 2001, Linus Torvalds wrote:
>
> Ok, the big thing here is continued merging, this time with Andrea.
>
> I still don't like some of the VM changes, but integrating Andrea's V=
M
> changes results in (a) better performance and (b) much cleaner inacti=
ve
> page handling in particular. Besides, for the 2.4.x tree, the big pri=
ority
> is stability, we can re-address my other concerns during 2.5.x.
Andrea,
Could you please make a resume of your VM changes ?
Its hard to keep up with VM changes this way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Mon, 17 Sep 2001 22:08:22 -0300 (BRT)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: marc...@freak.distro.conectiva
To: Linus Torvalds <torva...@transmeta.com>
Cc: Kernel Mailing List <linux-ker...@vger.kernel.org>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.21.0109172016200.6823-100000@freak.distro.conectiva>
Original-Message-ID: <Pine.LNX.4.21.0109172156490.6905-100000@freak.distro.conectiva>
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 02:34:34 GMT
Message-ID: <fa.ns0hmmv.v2q5br@ifi.uio.no>
References: <fa.nqvrm6v.s284rt@ifi.uio.no>
Lines: 51
On Mon, 17 Sep 2001, Marcelo Tosatti wrote:
>
>
> On Mon, 17 Sep 2001, Linus Torvalds wrote:
>
> >
> > Ok, the big thing here is continued merging, this time with Andrea.
> >
> > I still don't like some of the VM changes, but integrating Andrea's=
VM
> > changes results in (a) better performance and (b) much cleaner inac=
tive
> > page handling in particular. Besides, for the 2.4.x tree, the big p=
riority
> > is stability, we can re-address my other concerns during 2.5.x.
>
> Andrea,
>
> Could you please make a resume of your VM changes ?
>
> Its hard to keep up with VM changes this way.
Andrea,
I've just read a bit of your new VM code and I have a few comments.
You completly removed the "inactive freeable pages" logic: There is no
more distiction between "freeable inactive" and "free" pages. All VM wo=
rk
is based on "freepages.high" watermark. I don't like that: it seems to
make page freeing more aggressive over time.
Also, if we have several try_to_free_pages() callers, for different
classzones, I'm right saying that a caller with a "smaller" classzone c=
an
"hide" pages in its "active_local_lru" and/or "inactive_local_lru" (dur=
ing
shrink_cache) from other processes trying to free pages from those high=
er
zones ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!news-peer-west.sprintlink.net!news.sprintlink.net!
enews.sgi.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!
news-in.superfeed.net!news.exit.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Mon, 17 Sep 2001 19:27:31 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Benjamin LaHaise <b...@redhat.com>
X-cc: Andrea Arcangeli <and...@suse.de>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Message-ID: <linux.kernel.Pine.LNX.4.33.0109171919330.1068-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 61
On Mon, 17 Sep 2001, Benjamin LaHaise wrote:
>
> __builtin_expect. It just goes to show that you haven't bothered to get any
> feedback on this patch which is significantly invasive before merging it.
> This is completely unreasonable behaviour for a kernel series which is
> supposed to be stable.
No, it goes to show that I didn't actually apply all of Andrea's patches.
I left out a number of patches that I didn't see the point to, or that I
just plain disagreed with.
And some of the patches had some non-obvious dependencies, especially as I
have a reasonably recent compiler..
> The code in question does not attempt to explain itself at all. Your release
> notes did not explain what changes you did at all. Nor are your patches
> split up into reasonable chunks of functionality that can be evaluated based
> on their individual merit. All or nothing is *not* the approach that should
> be taken at present. (Hint, stability is acheived gradually.)
Actually, many of them _are_ split up, much more so than Alan's public
patches are (now, Alan in private splits up the patches really well, so
for me it tends to be even easier to apply Alans patches than Andreas, but
as with Alan, my one-liner "merged with xxxx" doesn't go into the detail
that Andrea and others actually do have).
Now, the VM part of the patch was certainly fairly big. I doubt much of it
could have been reasonably split up, though.
> No, what I'm deeply concerned with is the nature of patch merging. There was
> no obvious public testing of the changes before merging, no warning of it, the
> patch contained obvious bogus chunks and many unrelated changes. I've never
> seen as invasive a patch merged that ran the risk of completely torpedoing
> stability merged into a STABLE KERNEL SERIES, nor would I ever consider
> submitting such a patch. There are bug fixes that are outstanding in -ac
> that aren't being merged to -linus, yet this completely untested pile of messy
> code is merged without hesitation?
Without hesitation? Hardly.
The bug fixes in -ac that aren't merged into -linus are that way BECAUSE
NOBODY HAS SENT ME MERGES.
Alan works on it quite intensively, but the fact is, that for the -ac
merge, Alan seems to be able to merge it slower than -ac grows. Which is
why I actually started asking people to merge their parts from -ac into
-linus to help Alan. That's how the other merge in -pre11 happened.
The aa tree has existed for a long time, and is actually mainted in better
chunks than the -ac tree, which makes it easier to merge. Admittedly my
and Alans tastes are often closer than mine and Andreas, which means that
the -aa tree merges are more painful for _me_ ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!news-peer-west.sprintlink.net!news.sprintlink.net!
enews.sgi.com!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!
news-in.superfeed.net!news.exit.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux 2.4.10-pre11
X-To: torva...@transmeta.com (Linus Torvalds)
Date: Tue, 18 Sep 2001 04:14:01 +0100 (BST)
X-Cc: b...@redhat.com (Benjamin LaHaise), and...@suse.de (Andrea Arcangeli),
linux-ker...@vger.kernel.org (Kernel Mailing List)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E15jBKj-0008Tu-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 23
> The bug fixes in -ac that aren't merged into -linus are that way BECAUSE
> NOBODY HAS SENT ME MERGES.
Actually some of them I've sent you many times. The tlb fix I have on
my list of "dont bother" for example - which means I got bored of sending
it.
> Alan works on it quite intensively, but the fact is, that for the -ac
> merge, Alan seems to be able to merge it slower than -ac grows. Which is
> why I actually started asking people to merge their parts from -ac into
> -linus to help Alan. That's how the other merge in -pre11 happened.
I've been trying to ensure I feed stuff in testable chunks. For example
I dont want vfs and scsi changes both in a Linus merge because someone is
bound to go "hey I got corruption" and then with both in one merge we
are screwed
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 05:37:11 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Marcelo Tosatti <marc...@conectiva.com.br>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918053711.P698@athlon.random>
Original-References: <Pine.LNX.4.21.0109172016200.6823-100...@freak.distro.conectiva>
<Pine.LNX.4.21.0109172156490.6905-100...@freak.distro.conectiva>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0109172156490.6905-100000@freak.distro.conectiva>;
from marcelo@conectiva.com.br on Mon, Sep 17, 2001 at 10:08:22PM -0300
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 03:38:33 GMT
Message-ID: <fa.g7d4oov.1igeiau@ifi.uio.no>
References: <fa.ns0hmmv.v2q5br@ifi.uio.no>
Lines: 97
On Mon, Sep 17, 2001 at 10:08:22PM -0300, Marcelo Tosatti wrote:
>
>
> On Mon, 17 Sep 2001, Marcelo Tosatti wrote:
>
> >
> >
> > On Mon, 17 Sep 2001, Linus Torvalds wrote:
> >
> > >
> > > Ok, the big thing here is continued merging, this time with Andre=
a.
> > >
> > > I still don't like some of the VM changes, but integrating Andrea=
's VM
> > > changes results in (a) better performance and (b) much cleaner in=
active
> > > page handling in particular. Besides, for the 2.4.x tree, the big=
priority
> > > is stability, we can re-address my other concerns during 2.5.x.
> >
> > Andrea,
> >
> > Could you please make a resume of your VM changes ?
> >
> > Its hard to keep up with VM changes this way.
>
> Andrea,
>
> I've just read a bit of your new VM code and I have a few comments.
>
> You completly removed the "inactive freeable pages" logic: There is n=
o
yes, it wasn't relly useful to keep this list lazily, you either keep i=
t
enforced with locking overhead or such information isn't valuable.
> more distiction between "freeable inactive" and "free" pages. All VM =
work
> is based on "freepages.high" watermark. I don't like that: it seems t=
o
hardly on freepages.high:
diff -urN vm-ref/mm/swap.c vm/mm/swap.c
--- vm-ref/mm/swap.c Tue Sep 18 00:18:17 2001
+++ vm/mm/swap.c Tue Sep 18 00:18:35 2001
@@ -24,50 +24,13 @@
#include <asm/uaccess.h> /* for copy_to/from_user */
#include <asm/pgtable.h>
-/*
- * We identify three levels of free memory. We never let free mem
- * fall below the freepages.min except for atomic allocations. We
- * start background swapping if we fall below freepages.high free
- * pages, and we begin intensive swapping below freepages.low.
- *
- * Actual initialization is done in mm/page_alloc.c
- */
-freepages_t freepages = {
- 0, /* freepages.min */
- 0, /* freepages.low */
- 0 /* freepages.high */
-};
-
> make page freeing more aggressive over time.
I don't see your point with "page freeing more aggressive over time".
> Also, if we have several try_to_free_pages() callers, for different
> classzones, I'm right saying that a caller with a "smaller" classzone=
can
> "hide" pages in its "active_local_lru" and/or "inactive_local_lru" (d=
uring
> shrink_cache) from other processes trying to free pages from those hi=
gher
> zones ?
I'm deeply impressed, you seem to have understood the rewrite greatly
well, congrats, this "hiding" was infact my main concern I had on the
memclass check during shrink_cache, but I don't think this will ever
give us troubles. In such there are suprious swapouts with HIGHMEM
we'll just need to waste some cpu by lefting those pages visible with a
few changes in shrink_cache, but again I'm almost sure there won't be
problems, we do multiple scans before failing so those pages will retur=
n
visible before the other task has a chance to fail the allocation.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Tue, 18 Sep 2001 00:01:32 -0400
From: Benjamin LaHaise <b...@redhat.com>
X-To: Andrea Arcangeli <and...@suse.de>
X-Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Message-ID: <linux.kernel.20010918000132.C885@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 166
On Tue, Sep 18, 2001 at 05:22:01AM +0200, Andrea Arcangeli wrote:
> try compiling 2.4.10pre10aa1 with egcs 1.1.2 before complaing about lack
> of testing, the tests were run on 2.4.10pre10aa1, not on 2.4.10pre11
> that didn't even existed at that time.
If I spent the time testing every random kernel patch that comes across, then
I wouldn't have any time left to develop other useful things. What I see is
that what was merged didn't deal with things sanely.
> So I'm not surprised by the fact you weren't horrified by the previous
> VM that was looping forever in such a case. unfortunately not everybody
> out there (mainly simulations) knows how much memory they will alloc.
Every single kernel since the dawn of 1.0 has died under OOM. Optimizing for
it seems rather stupid when a well maintained box WON'T OOM.
> > Then why wasn't it added to the generic code?
>
> see above.
So merging crap is now acceptable? Great, I'll write messy code from now on.
> > on their individual merit. All or nothing is *not* the approach that should
> > be taken at present. (Hint, stability is acheived gradually.)
>
> You can find a very big split if you check into the 2.4.10pre10aa1/
> directory in my ftp area, of course if you look at 2.4.10pre11 it is all
> at once.
Yes, all of the vm patches are in one big 3300 line patch, which is about the
same size as the entire aio patch which adds a new subsystem.
> For the vm changes properly splitting them it's quite a pain, mainly due
> the way they're developed. For everything that is not a pain to keep
> separated I try to do so.
Bull shit. People do it every day because Linus dictates it so. There is
nothing magical in you patch that can't be split up into human-readable
chunks.
> > > again and you'll see, as said 2.2.19 does the same write throttling.
> >
> > And it does so in a fashion which is completely broken.
>
> Then send Alan the fix against 2.2.20pre10 if it's completly broken. I
> never got a complain about it yet and I look forward to see your fix.
2.2 doesn't matter any more. Any work I'm doing now is 2.4 based.
>
> > Then make it a seperate patch. It shouldn't be part of the do-everything
>
> Please get real, it is a 3 thousand lines patch, if for every single
> change like this (orthogonal with the rest) I should make 1 patch it
> would take hours just to run the diffs. Not to tell if then I make a
> controversial changes.
I am being real. I don't expect single massive patches to ever be applied,
and am shocked I've even had to comment on this.
> What kind of workload is applied during the measurement, and what
> NULL/MEM/FILE_IO/PROCESS means? Is this benchmark available somewhere?
> What fields are you looking at exactly? I can see some field going up
> and low and I cannot evaluate those numbers very well without more info.
Go do the work yourself. If you can't be bothered to develop benchmarks that
simulate users on the vm subsystem, how can you claim your vm patches are
correct?
> Except for the vm rewrite there was extensive testing. Probably not from
> RedHat Inc if this is the point that you are making. And the vm rewrite
> is so obviously better and much cleaner that I think this was a fine
> integration. I'm pretty sure no stability problem can arise because of
> the vm integration, if there could be problems as worse they could be
> specific to slower performance in some workload which we can address
> over the time without any pain. anyways as said dbench runs exactly
> twice faster so it cannot be obviously wrong in terms of performance
> either.
So the vm rewrite wasn't well tested, but it should be merged into a stable
kernel? Please say it ain't so.
> Linus merged everything without asking me and I think his move was very
> good IMHO. Face it: users cannot live anymore with workloads slowing
> down at every runs of benchmarks, with kswapd looping forever, with
> swapout storms, with swap filled by unused swapcache etc... What I did
> is the less intrusive change to the code that could at least address
> those critical problems and I'm pretty sure it did, as worse as said we
> may need some little tweak over the time but the new infrastructure
> should be robust enough now.
I want robust and not likely to corrupt my data randomly. The latter is more
important to me and everyone else in the world, so I think you should play
by rules that enforce that.
> Ben, the true mess is the 2.4 VM before 2.4.10pre11. Period.
Sure.
> If you
> check the new code you'll see how much cleaner it is.
Hardly. You don't even define your basic terms. WTF is a classzone? A
comment somewhere would be nice.
> Those locking changes are bugfixes. Try to growsdown on a file backed
> vma with 2.4.9 using two threads and you'll run into troubles eventually
> (see the thread on l-k).
That isn't the one I'm talking about. You changed the swapcache code. That
code is fragile. These changes aren't documented.
> Just in case it wasn't obvious I do things gradually and in public,
> check ftp.kernel.org. If something you're the one that doesn't care
> about what I do in public.
The vm rewrite was not posted in public, nor described in public. It just
appeared and got merged. Could you at least describe *ALL* of the changes?
> I recall I also described you some of the O_DIRECT
> stuff and blkdev pagecache work on Ottawa a few months ago. I get lots
> of feedback and also bugfixes from many places, to mention one company
> that cares about what I do in public there's IBM, they did auditing and
> I got several O_DIRECT small fixes from them incrementally to my very
> open patches. I think -aa I'm even more open than -ac since I keep all
> the stuff separated so it's much easier to understand and pick the
> interesting parts. I do my best effort to make every patch self
> contained just for the purpose of making merging and auditing easier,
> and it payed off so far. Furthmore it's not just in public but also in
> production, for istsance all SuSE server users happily runs things like
> O_DIRECT and blkdev in pagecache for several months now. The latter was
> needed from a few I/O intensive applications using blkdevs as files and
> needing heavy readhead for exploiting the full bandwith of many-ways
> raid arrays for example. The only other way would been to basically
> duplicate the readahead of filemap.c in block_dev.c, the hack was as
> complex as the long term fix.
And we agreed that this is 2.5 material.
> > Not at the expense of stability. Do it in 2.5, or do it gradually.
>
> Ben, instead of writing complains could you grab 2.4.10pre11, put it on
> your desktop while doing your daily work and let me know when you run
> into stability troubles? I could have said the same thing of the ext2
> directory metadata in pagecache, I grabbed it, put it on my desktop, it
> never given me a problem so far so I didn't complained. And the directory
> in pagecache wasn't fixing _any_ problem for the end user, here we're
> instead fixing _real_life_ showstopper problems with mysql, postgres (I
> wonder you care about postrgres these days?) and the other db not using
> rawio+lvm, so this was kind of needed in 2.4 eventually anyways if not
> today (I was flooded by bugreports of such kind, I'm sure you got them
> too). So the earlier the better. I think users would been not happy to
> wait until 2.6.
I'm sorry, but I'm not going to run it right now since I have other
priorities. I'm sure users will post their pass/fails over the next few
days, but until I see some evidence that it doesn't eat my data, I'll hold
back.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 06:39:10 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Benjamin LaHaise <b...@redhat.com>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918063910.U698@athlon.random>
Original-References:
<Pine.LNX.4.33.0109171608310.1108-100...@penguin.transmeta.com>
<20010917211834.A31...@redhat.com> <20010918035055.J...@athlon.random>
<20010917221653.B31...@redhat.com> <20010918052201.N...@athlon.random>
<20010918000132.C...@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20010918000132.C885@redhat.com>;
from bcrl@redhat.com on Tue, Sep 18, 2001 at 12:01:32AM -0400
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 04:42:36 GMT
Message-ID: <fa.g7d4opv.1igaial@ifi.uio.no>
References: <fa.fgs002v.121q9rv@ifi.uio.no>
Lines: 70
On Tue, Sep 18, 2001 at 12:01:32AM -0400, Benjamin LaHaise wrote:
> Every single kernel since the dawn of 1.0 has died under OOM. Optimizing for
try 2.2 once.
> 2.2 doesn't matter any more. Any work I'm doing now is 2.4 based.
It still matters for me. Critical servers with very high vm loads still
have to run 2.2 to be stable and fast unfortunately.
> I am being real. I don't expect single massive patches to ever be applied,
> and am shocked I've even had to comment on this.
Your aio patch is massive too.
andrea@athlon:~ > wc -l aio-v2.4.0-20010123.diff
2951 aio-v2.4.0-20010123.diff
Now if you think I'm unreal and you are real, feed me the aio patch in
self contained pieces of 10 lines each as you expect from me. And note
that if they're not self contained they will just make my life harder.
I'd be glad to be proved wrong and to get aio from you in small self
contained pieces really, I planned to look into aio as one of the next
things to merge in -aa but as usual the size of the patch makes things
harder to merge due the larger implications. feel free to cc l-k, I'm
sure other people is interested in aio too.
> I want robust and not likely to corrupt my data randomly. The latter is more
Forget the corruption. So far the only scary report I had is from
Marcelo's 2G machine which is nothin compared to corruption, I don't
have x86 machines with more than 1G, I tested alpha with 3G (but it has
only 1 zone). I think Marcelo identified the problematic part before
even testing it, so the fix should be fairly immediate, I'll address it
ASAP unless he beats me on it (at the moment I'm still resynching).
> That isn't the one I'm talking about. You changed the swapcache code. That
> code is fragile. These changes aren't documented.
I didn't changed the swapcache locking rules. I only fixed the VM to
properly clear the dirty bit before freeing a page. Anybody freeing a
page that is dirty was a plain vm bug. That was quite strightforward and
correct change. Infact I was horrified by seeing __free_pages_ok
clearing the dirty bit (not to talk about the referenced bit which was
useless to change).
> The vm rewrite was not posted in public, nor described in public. It just
It obviously was. How do you think Linus got it? I said I didn't sent it
to Linus privately.
> appeared and got merged. Could you at least describe *ALL* of the changes?
I'll be glad to do that over the time, right now I'm strict in time and
I also needed to go to sleep a few hours ago so I won't inline the reply
to this email right now, sorry.
> And we agreed that this is 2.5 material.
the O_DIRECT and blkdev in pagecache yes but definitely not the VM one
but people needed those features in production anyways so that was good
and they were well tested.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 00:33:15 -0300 (BRT)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: marc...@freak.distro.conectiva
To: Andrea Arcangeli <and...@suse.de>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <20010918065423.W698@athlon.random>
Original-Message-ID: <Pine.LNX.4.21.0109180031210.7152-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 04:59:00 GMT
Message-ID: <fa.nqffnev.tio5jk@ifi.uio.no>
References: <fa.g7tap9v.1j0cjqq@ifi.uio.no>
Lines: 19
On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> On Mon, Sep 17, 2001 at 11:53:10PM -0300, Marcelo Tosatti wrote:
> > Don't you agree that your code can introduce new stability bugs ?
>
> not anything that can corrupt randomly your hd.
Sure, the old code did not corrupt hd's randomly, did it?
Let me redo the question: Don't you think the old stinky and slow code was
reasonably stable ? :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Subject: Re: Linux 2.4.10-pre11
X-To: and...@suse.de (Andrea Arcangeli)
Date: Tue, 18 Sep 2001 06:04:28 +0100 (BST)
X-Cc: b...@redhat.com (Benjamin LaHaise),
torva...@transmeta.com (Linus Torvalds),
linux-ker...@vger.kernel.org (Kernel Mailing List)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <linux.kernel.E15jD3c-0000Ga-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Approved: n...@nntp-server.caltech.edu
Lines: 17
> > And we agreed that this is 2.5 material.
>
> the O_DIRECT and blkdev in pagecache yes but definitely not the VM one
> but people needed those features in production anyways so that was good
> and they were well tested.
The O_DIRECT stuff is very clean - its definitely a feature that should
have gone into 2.5 first and then back, but its one that really doesn't
bother me too much. blkdev in page cache needs some locking thinking but
looks ok.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 07:06:54 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Marcelo Tosatti <marc...@conectiva.com.br>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918070654.Y698@athlon.random>
Original-References: <20010918065423.W...@athlon.random>
<Pine.LNX.4.21.0109180031210.7152-100...@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0109180031210.7152-100000@freak.distro.conectiva>;
from marcelo@conectiva.com.br on Tue, Sep 18, 2001 at 12:33:15AM -0300
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 05:08:36 GMT
Message-ID: <fa.g9deo1v.1gg0iim@ifi.uio.no>
References: <fa.nqffnev.tio5jk@ifi.uio.no>
Lines: 24
On Tue, Sep 18, 2001 at 12:33:15AM -0300, Marcelo Tosatti wrote:
>
> On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
>
> > On Mon, Sep 17, 2001 at 11:53:10PM -0300, Marcelo Tosatti wrote:
> > > Don't you agree that your code can introduce new stability bugs ?
> >
> > not anything that can corrupt randomly your hd.
>
> Sure, the old code did not corrupt hd's randomly, did it?
>
> Let me redo the question: Don't you think the old stinky and slow code was
> reasonably stable ? :)
As said in the other email, just check 2.4 l-k reports of this week,
last week etc.., I've lots of private reports too. While for everybody
2.2.19 is working fine.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 00:55:46 -0300 (BRT)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: marc...@freak.distro.conectiva
To: Andrea Arcangeli <and...@suse.de>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <20010918070654.Y698@athlon.random>
Original-Message-ID: <Pine.LNX.4.21.0109180050490.7152-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 05:23:16 GMT
Message-ID: <fa.nrfvnuv.ui843l@ifi.uio.no>
References: <fa.g9deo1v.1gg0iim@ifi.uio.no>
Lines: 37
On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> On Tue, Sep 18, 2001 at 12:33:15AM -0300, Marcelo Tosatti wrote:
> >
> > On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> >
> > > On Mon, Sep 17, 2001 at 11:53:10PM -0300, Marcelo Tosatti wrote:
> > > > Don't you agree that your code can introduce new stability bugs ?
> > >
> > > not anything that can corrupt randomly your hd.
> >
> > Sure, the old code did not corrupt hd's randomly, did it?
> >
> > Let me redo the question: Don't you think the old stinky and slow code was
> > reasonably stable ? :)
>
> As said in the other email, just check 2.4 l-k reports of this week,
> last week etc.., I've lots of private reports too. While for everybody
> 2.2.19 is working fine.
Have you seen any problem report which does not happen with anon intensive
workloads ?
As far as I've noted, people usually report performance problems when
running anon intensive workloads. For those cases, I'm pretty sure the
swap_out() loop is the fuckup: the swap allocation code is really a _CRAP_
for the current VM.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 01:22:16 -0400
From: Benjamin LaHaise <b...@redhat.com>
To: Andrea Arcangeli <and...@suse.de>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918012216.C1249@redhat.com>
Original-References:
<Pine.LNX.4.33.0109171608310.1108-100...@penguin.transmeta.com>
<20010917211834.A31...@redhat.com> <20010918035055.J...@athlon.random>
<20010917221653.B31...@redhat.com> <20010918052201.N...@athlon.random>
<20010918000132.C...@redhat.com> <20010918063910.U...@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010918063910.U698@athlon.random>;
from andrea@suse.de on Tue, Sep 18, 2001 at 06:39:10AM +0200
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 05:23:16 GMT
Message-ID: <fa.dmudchv.r421qc@ifi.uio.no>
References: <fa.g7d4opv.1igaial@ifi.uio.no>
Lines: 95
On Tue, Sep 18, 2001 at 06:39:10AM +0200, Andrea Arcangeli wrote:
> On Tue, Sep 18, 2001 at 12:01:32AM -0400, Benjamin LaHaise wrote:
> > Every single kernel since the dawn of 1.0 has died under OOM. Optimizing for
>
> try 2.2 once.
There are still loads that 2.2 can die under (think fast network cards and
you'll realise that you can't protect against it). Yes, 2.2 is in far better
state than anything else ever has been, but it's not perfect.
> > 2.2 doesn't matter any more. Any work I'm doing now is 2.4 based.
>
> It still matters for me. Critical servers with very high vm loads still
> have to run 2.2 to be stable and fast unfortunately.
That's where I want 2.4 to get to.
> > I am being real. I don't expect single massive patches to ever be applied,
> > and am shocked I've even had to comment on this.
>
> Your aio patch is massive too.
>
> andrea@athlon:~ > wc -l aio-v2.4.0-20010123.diff
> 2951 aio-v2.4.0-20010123.diff
>
> Now if you think I'm unreal and you are real, feed me the aio patch in
> self contained pieces of 10 lines each as you expect from me. And note
> that if they're not self contained they will just make my life harder.
Not 10 lines, but several hundred here and there. Aio actually splits up
very well since thing like the wait_queue changes are all isolated bits
of functionality. Even the brw_kiovec_async bit is standalone since it
only matters to itself and brw_kiovec. Yes, the current patch is not
seperated, but that was my plan from the beginning on merging.
> I'd be glad to be proved wrong and to get aio from you in small self
> contained pieces really, I planned to look into aio as one of the next
> things to merge in -aa but as usual the size of the patch makes things
> harder to merge due the larger implications. feel free to cc l-k, I'm
> sure other people is interested in aio too.
It's not ready yet. Most of the development has been on hold waiting for
2.5 to start for cementing the ABI in stone.
> > I want robust and not likely to corrupt my data randomly. The latter is more
>
> Forget the corruption. So far the only scary report I had is from
> Marcelo's 2G machine which is nothin compared to corruption, I don't
> have x86 machines with more than 1G, I tested alpha with 3G (but it has
> only 1 zone). I think Marcelo identified the problematic part before
> even testing it, so the fix should be fairly immediate, I'll address it
> ASAP unless he beats me on it (at the moment I'm still resynching).
Sure. That's why it should remain seperate for at least a little bit.
>
> > That isn't the one I'm talking about. You changed the swapcache code. That
> > code is fragile. These changes aren't documented.
>
> I didn't changed the swapcache locking rules. I only fixed the VM to
> properly clear the dirty bit before freeing a page. Anybody freeing a
> page that is dirty was a plain vm bug. That was quite strightforward and
> correct change. Infact I was horrified by seeing __free_pages_ok
> clearing the dirty bit (not to talk about the referenced bit which was
> useless to change).
So why not split that fix out as a seperate patch that can then be applied
alone?
>
> > The vm rewrite was not posted in public, nor described in public. It just
>
> It obviously was. How do you think Linus got it? I said I didn't sent it
> to Linus privately.
*nod*
> > appeared and got merged. Could you at least describe *ALL* of the changes?
>
> I'll be glad to do that over the time, right now I'm strict in time and
> I also needed to go to sleep a few hours ago so I won't inline the reply
> to this email right now, sorry.
Thanks! I think we'll all be a bit calmer in the morning and better able to
think clearly. I'll even try to break things down a bit as there are bits
in your patches which I think are very good.
Cheers,
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 07:32:48 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Marcelo Tosatti <marc...@conectiva.com.br>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918073248.G698@athlon.random>
Original-References: <20010918070654.Y...@athlon.random>
<Pine.LNX.4.21.0109180050490.7152-100...@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0109180050490.7152-100000@freak.distro.conectiva>;
from marcelo@conectiva.com.br on Tue, Sep 18, 2001 at 12:55:46AM -0300
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 05:34:10 GMT
Message-ID: <fa.g8tmoov.1g0oiac@ifi.uio.no>
References: <fa.nrfvnuv.ui843l@ifi.uio.no>
Lines: 43
On Tue, Sep 18, 2001 at 12:55:46AM -0300, Marcelo Tosatti wrote:
>
>
> On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
>
> > On Tue, Sep 18, 2001 at 12:33:15AM -0300, Marcelo Tosatti wrote:
> > >
> > > On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> > >
> > > > On Mon, Sep 17, 2001 at 11:53:10PM -0300, Marcelo Tosatti wrote:
> > > > > Don't you agree that your code can introduce new stability bugs ?
> > > >
> > > > not anything that can corrupt randomly your hd.
> > >
> > > Sure, the old code did not corrupt hd's randomly, did it?
> > >
> > > Let me redo the question: Don't you think the old stinky and slow code was
> > > reasonably stable ? :)
> >
> > As said in the other email, just check 2.4 l-k reports of this week,
> > last week etc.., I've lots of private reports too. While for everybody
> > 2.2.19 is working fine.
>
> Have you seen any problem report which does not happen with anon intensive
> workloads ?
of course, all the mysql/postgres db reports I got were non anon
intensive I assume, I assume they had enough ram, they all said 2.2 was
fine.
> As far as I've noted, people usually report performance problems when
> running anon intensive workloads. For those cases, I'm pretty sure the
> swap_out() loop is the fuckup: the swap allocation code is really a _CRAP_
> for the current VM.
I don't think that was the case, 2.2 has the same swap_out loop.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 01:14:36 -0300 (BRT)
From: Marcelo Tosatti <marc...@conectiva.com.br>
X-Sender: marc...@freak.distro.conectiva
To: Andrea Arcangeli <and...@suse.de>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <20010918073248.G698@athlon.random>
Original-Message-ID: <Pine.LNX.4.21.0109180111550.7152-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 05:40:17 GMT
Message-ID: <fa.nrvpmuv.u2i53k@ifi.uio.no>
References: <fa.g8tmoov.1g0oiac@ifi.uio.no>
Lines: 50
On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> On Tue, Sep 18, 2001 at 12:55:46AM -0300, Marcelo Tosatti wrote:
> >
> >
> > On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> >
> > > On Tue, Sep 18, 2001 at 12:33:15AM -0300, Marcelo Tosatti wrote:
> > > >
> > > > On Tue, 18 Sep 2001, Andrea Arcangeli wrote:
> > > >
> > > > > On Mon, Sep 17, 2001 at 11:53:10PM -0300, Marcelo Tosatti wrote:
> > > > > > Don't you agree that your code can introduce new stability bugs ?
> > > > >
> > > > > not anything that can corrupt randomly your hd.
> > > >
> > > > Sure, the old code did not corrupt hd's randomly, did it?
> > > >
> > > > Let me redo the question: Don't you think the old stinky and slow code was
> > > > reasonably stable ? :)
> > >
> > > As said in the other email, just check 2.4 l-k reports of this week,
> > > last week etc.., I've lots of private reports too. While for everybody
> > > 2.2.19 is working fine.
> >
> > Have you seen any problem report which does not happen with anon intensive
> > workloads ?
>
> of course, all the mysql/postgres db reports I got were non anon
> intensive I assume, I assume they had enough ram, they all said 2.2 was
> fine.
>
> > As far as I've noted, people usually report performance problems when
> > running anon intensive workloads. For those cases, I'm pretty sure the
> > swap_out() loop is the fuckup: the swap allocation code is really a _CRAP_
> > for the current VM.
>
> I don't think that was the case, 2.2 has the same swap_out loop.
Note that in 2.4 we scan pte's even if there is no free pages
shortage, while in 2.2 we only scan pte's if there is a free page
shortage.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: vasquez.zip.com.au: Host r...@zipperii.zip.com.au
[61.8.0.87] claimed to be zip.com.au
Original-Message-ID: <3BA6E032.587A1DBF@zip.com.au>
Original-Date: Mon, 17 Sep 2001 22:48:34 -0700
From: Andrew Morton <a...@zip.com.au>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-ac10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linus Torvalds <torva...@transmeta.com>
CC: Kernel Mailing List <linux-ker...@vger.kernel.org>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: Linux 2.4.10-pre11
Original-References: <Pine.LNX.4.33.0109171608310.1108-100...@penguin.transmeta.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 05:49:54 GMT
Message-ID: <fa.e1u5k5v.2nitqg@ifi.uio.no>
References: <fa.oaa1c7v.gkm5rb@ifi.uio.no>
Lines: 55
Linus Torvalds wrote:
>
> Ok, the big thing here is continued merging, this time with Andrea.
>
In one test here the VM changes seem fragile, and slower.
Dual x86, 512 megs RAM, 512 megs swap. No highmem.
The workload is:
while true
do
/usr/src/ext3/tools/usemem 300
done
(This just mallocs 300 megs, touches it then exits)
in parallel with
time /usr/src/ext3/tools/bash-shared-mapping -n 5 -t 3 foo 300000000
on ext2.
(bash-shared-mapping is a tool which I wrote for ext3. It's one of the
most aggressive VM/MM stress testers around, and has found a number of
kernel bugs).
On 2.4.9-ac10, the b-s-m run took 294 seconds. On 2.4.10-pre11 it
took 330 seconds DESPITE the fact that one of the b-s-m instances
was oom-killed quite early in the test.
`vmstat' took about thirty seconds to start (this is usual), but
was promptly killed, despite having (presumably) a small RSS. Instances
of `usemem' were oom-killed quite frequently. In 2.4.9-ac10, nothing
was oom-killed.
With a gig of VM and a 600 meg working set I don't see why it's necessary
to kill processes? Each oom-kill was associated with a 0-order allocation
failure.
These tools are available at http://www.uow.edu.au/~andrewm/ext3-tools.tar.gz
OK, so this was a seriously loony workload. But suddenly, the number of people
who understand the Linux VM has gone from maybe 10 down to just one-and-a-bit.
A large number of comments have been removed, and a year's worth of
discussion has been invalidated.
Andrea, it would be most useful if you were to spend some time (say, four hours)
commenting the code and telling us how it works.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 07:59:27 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Marcelo Tosatti <marc...@conectiva.com.br>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918075927.I698@athlon.random>
Original-References: <20010918073248.G...@athlon.random>
<Pine.LNX.4.21.0109180111550.7152-100...@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0109180111550.7152-100000@freak.distro.conectiva>;
from marcelo@conectiva.com.br on Tue, Sep 18, 2001 at 01:14:36AM -0300
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 06:01:25 GMT
Message-ID: <fa.g7tkp8v.1j06jq9@ifi.uio.no>
References: <fa.nrvpmuv.u2i53k@ifi.uio.no>
Lines: 20
On Tue, Sep 18, 2001 at 01:14:36AM -0300, Marcelo Tosatti wrote:
> Note that in 2.4 we scan pte's even if there is no free pages
> shortage, while in 2.2 we only scan pte's if there is a free page
> shortage.
That was most certainly a problem which is now fixed. Mainly the
preallication of swap was a waste. But I think there was a kind of
physical (not pte) overaging too that forbidden the vm to react
properly.
I believe when the storm of swap_out startups it won't matter any longer
what we aged and whatever pte scanning we did previously. At least with
the current swap_out.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Mon, 17 Sep 2001 23:14:30 -0700 (PDT)
From: Alexei Podtelezhnikov <apodt...@mccammon.ucsd.edu>
X-Sender: apodtele@mccammon
To: linux-ker...@vger.kernel.org
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <Pine.GSO.4.05.10109172308400.28747-100000@mccammon>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 06:14:07 GMT
Message-ID: <fa.isch9jv.162kujc@ifi.uio.no>
Lines: 12
I praise Linus for this step.
Since 9-10 months ago Rik's scheme didn't det enough attention
to get fixed. Out of the main tree it has better chances, just like it did
before inclusion.
Alexei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 08:11:46 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Andrew Morton <a...@zip.com.au>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918081146.J698@athlon.random>
Original-References:
<Pine.LNX.4.33.0109171608310.1108-100...@penguin.transmeta.com>
<3BA6E032.587A1...@zip.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3BA6E032.587A1DBF@zip.com.au>;
from akpm@zip.com.au on Mon, Sep 17, 2001 at 10:48:34PM -0700
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 06:14:07 GMT
Message-ID: <fa.g8tko8v.1g0qiq2@ifi.uio.no>
References: <fa.e1u5k5v.2nitqg@ifi.uio.no>
Lines: 59
On Mon, Sep 17, 2001 at 10:48:34PM -0700, Andrew Morton wrote:
> Linus Torvalds wrote:
> >
> > Ok, the big thing here is continued merging, this time with Andrea.
> >
>
> In one test here the VM changes seem fragile, and slower.
>
> Dual x86, 512 megs RAM, 512 megs swap. No highmem.
>
> The workload is:
>
> while true
> do
> /usr/src/ext3/tools/usemem 300
> done
>
> (This just mallocs 300 megs, touches it then exits)
>
> in parallel with
>
> time /usr/src/ext3/tools/bash-shared-mapping -n 5 -t 3 foo 300000000
>
> on ext2.
>
> (bash-shared-mapping is a tool which I wrote for ext3. It's one of the
> most aggressive VM/MM stress testers around, and has found a number of
> kernel bugs).
>
> On 2.4.9-ac10, the b-s-m run took 294 seconds. On 2.4.10-pre11 it
> took 330 seconds DESPITE the fact that one of the b-s-m instances
> was oom-killed quite early in the test.
>
> `vmstat' took about thirty seconds to start (this is usual), but
> was promptly killed, despite having (presumably) a small RSS. Instances
> of `usemem' were oom-killed quite frequently. In 2.4.9-ac10, nothing
> was oom-killed.
should be the very same problem identified by Marcelo. I'm wondering why
I didn't reproduced here during testing, 512mbytes is not highmem and my
desktop has 512mbytes too and it didn't killed anything yet. As for the
slowdown there are a few localized places to look at. but let's fix the
oom first.
> Andrea, it would be most useful if you were to spend some time (say, four hours)
> commenting the code and telling us how it works.
I will do that and I'll answer to any question ASAP, no panic. We may
even want to change part of the core logic over time if it doesn't
perform wonderfully. But first prio at the moment is to fix the oom you
also noticed (the "hiding" logic mentioned by Marcelo), the rest of the
changes should be a very solid base for a very solid and fast 2.4 vm.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Original-Date: Tue, 18 Sep 2001 05:31:48 -0400 (EDT)
From: Alexander Viro <v...@math.psu.edu>
To: Linus Torvalds <torva...@transmeta.com>
cc: Kernel Mailing List <linux-ker...@vger.kernel.org>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.33.0109171608310.1108-100000@penguin.transmeta.com>
Original-Message-ID: <Pine.GSO.4.21.0109180527450.25323-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 09:33:31 GMT
Message-ID: <fa.mgrds3v.l4crbo@ifi.uio.no>
References: <fa.oaa1c7v.gkm5rb@ifi.uio.no>
Lines: 19
On Mon, 17 Sep 2001, Linus Torvalds wrote:
> This also merges the blkdev in page cache patch, and that will hopefully
> make it noticeably easier to do the "do bread() with page cache too", at
> which point a lot of the current ugly synchronization issues will go away.
Umm... Linus, had you actually read through the fs/block_device.c part
of that? It's not just ugly as hell, it's (AFAICS) not hard to oops
if you have several inodes sharing major:minor. ->bd_inode and its
treatment are bogus. Please, read it through and consider reverting -
in its current state code is an ugly mess.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 10:51:30 -0300 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender: <r...@imladris.rielhome.conectiva>
To: Alexei Podtelezhnikov <apodt...@mccammon.ucsd.edu>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.GSO.4.05.10109172308400.28747-100000@mccammon>
Original-Message-ID:
<Pine.LNX.4.33L.0109181049110.29584-100000@imladris.rielhome.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 13:55:03 GMT
Message-ID: <fa.qaq6n5v.1qlqng6@ifi.uio.no>
References: <fa.isch9jv.162kujc@ifi.uio.no>
Lines: 28
On Mon, 17 Sep 2001, Alexei Podtelezhnikov wrote:
> Since 9-10 months ago Rik's scheme didn't det enough attention to get
> fixed. Out of the main tree it has better chances, just like it did
> before inclusion.
Umm, we _have_ been fixing the VM in 2.4, but Linus has
been randomly ignoring patches and introducing stuff
we warned him not to apply which broke stuff.
With maintainance like that, I'm sure Andrea's code
will also have a better chance out of the main tree ;)
cheers,
Rik
--
IA64: a worthy successor to i860.
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardv...@nl.linux.org (spam digging piggy)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Tue, 18 Sep 2001 09:45:00 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
To: Alexander Viro <v...@math.psu.edu>
cc: Kernel Mailing List <linux-ker...@vger.kernel.org>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.GSO.4.21.0109180527450.25323-100000@weyl.math.psu.edu>
Original-Message-ID: <Pine.LNX.4.33.0109180935180.2077-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 16:47:43 GMT
Message-ID: <fa.o9ajenv.gko4r6@ifi.uio.no>
References: <fa.mgrds3v.l4crbo@ifi.uio.no>
Lines: 32
On Tue, 18 Sep 2001, Alexander Viro wrote:
>
> Umm... Linus, had you actually read through the fs/block_device.c part
> of that? It's not just ugly as hell, it's (AFAICS) not hard to oops
> if you have several inodes sharing major:minor. ->bd_inode and its
> treatment are bogus. Please, read it through and consider reverting -
> in its current state code is an ugly mess.
Funny that you mention it, because I actually have a cunning plan, and
you're an unwitting part of it.
Or actually, I hope you're a "witting" part of it, because it's going to
be your code.
Take your "struct block_device" code, add a "struct address_space" to it,
and whenever a block device inode is opened, make the inode->i_mapping
point to &bdev->b_data, and voila..
You already get all the reference counting right, and it's the only
sensible place to do it anyway, wouldn't you agree?
I thought you'd be thrilled. It seems to match your lazy allocation patch
very well..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Original-Date: Tue, 18 Sep 2001 14:19:42 -0400 (EDT)
From: Alexander Viro <v...@math.psu.edu>
To: Linus Torvalds <torva...@transmeta.com>
cc: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.33.0109180935180.2077-100000@penguin.transmeta.com>
Original-Message-ID: <Pine.GSO.4.21.0109181354470.27125-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 18:20:57 GMT
Message-ID: <fa.mibhsav.mk0q3r@ifi.uio.no>
References: <fa.o9ajenv.gko4r6@ifi.uio.no>
Lines: 64
On Tue, 18 Sep 2001, Linus Torvalds wrote:
>
> On Tue, 18 Sep 2001, Alexander Viro wrote:
> >
> > Umm... Linus, had you actually read through the fs/block_device.c part
> > of that? It's not just ugly as hell, it's (AFAICS) not hard to oops
> > if you have several inodes sharing major:minor. ->bd_inode and its
> > treatment are bogus. Please, read it through and consider reverting -
> > in its current state code is an ugly mess.
>
> Funny that you mention it, because I actually have a cunning plan, and
> you're an unwitting part of it.
/me swears
Yes, we can make it work that way (see downthread). Yes, combined with
lazy allocation (and pipefs-like scheme) it can turn into nice, _working_
code.
But right now we have
a) broken patch applied to the tree
b) somewhat tested patch that may (after being modified so that it
would _apply_ to -pre11) fix the breakage. Once it's tested enough to
be consider as a candidate for inclusion, that is.
IMNSHO it's somewhat less than ideal situation. I've already talked to
with Andrea and once he gets back to life (no, 'e's just sleepin') we'll
try to do something usable. Life would be much simpler if aforementioned
cunning plan included sending mail to participants (me and Andrea) before
putting the patch into the tree, though. Oh, well...
> Or actually, I hope you're a "witting" part of it, because it's going to
> be your code.
>
> Take your "struct block_device" code, add a "struct address_space" to it,
> and whenever a block device inode is opened, make the inode->i_mapping
> point to &bdev->b_data, and voila..
>
> You already get all the reference counting right, and it's the only
> sensible place to do it anyway, wouldn't you agree?
>
> I thought you'd be thrilled. It seems to match your lazy allocation patch
> very well..
It can be modified so that combination with lazy-bdev and pipefs-like tree
would work. And yes, most of the ugliness would just go away.
The problem being, I'd rather do it in a different order -
1) finish testing of lazy-bdev
2) apply well-tested patch
3) test modified bedv-in-pagecache patch
4) apply it, once it got public testing.
As it is, we'll do combined patch, diff it against -pre11 and submit
for inclusion - new hole in the main tree needs fixing...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Tue, 18 Sep 2001 11:27:27 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
To: Alexander Viro <v...@math.psu.edu>
cc: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.GSO.4.21.0109181354470.27125-100000@weyl.math.psu.edu>
Original-Message-ID: <Pine.LNX.4.33.0109181122550.9711-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 18:29:50 GMT
Message-ID: <fa.ofabcuv.nks537@ifi.uio.no>
References: <fa.mibhsav.mk0q3r@ifi.uio.no>
Lines: 30
On Tue, 18 Sep 2001, Alexander Viro wrote:
>
> It can be modified so that combination with lazy-bdev and pipefs-like tree
> would work. And yes, most of the ugliness would just go away.
That's the part I like about the page-cache bdev patch. It has a lot of
fairly ugly warts, but all of them seem to be really fixable with _other_
cleanups, at which point only the good parts remain.
I agree that the timing may leave something to be desired. But we had the
discussion about fixing pagecache-bdev consistency wrt the regular buffer
cache filesystem accesses a week or so ago, and the fact is that nobody
really seems to have started working on it - because everybody felt that
you have to get everything done at once.
I don't have that feeling. I'm happy with having partial merge with ugly
warts, if it means that you can get to the final stage _without_ having to
have all the problems fixed at one time.
So now we have two _smaller_ merges that will fix two other issues, and
remove all the horridness from the original merge.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!news.algonet.se!algonet!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
From: Andreas Dilger <adil...@turbolabs.com>
Original-Date: Tue, 18 Sep 2001 13:14:19 -0600
To: Linus Torvalds <torva...@transmeta.com>
Cc: Alexander Viro <v...@math.psu.edu>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010918131419.A14526@turbolinux.com>
Mail-Followup-To: Linus Torvalds <torva...@transmeta.com>,
Alexander Viro <v...@math.psu.edu>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Original-References:
<Pine.GSO.4.21.0109181354470.27125-100...@weyl.math.psu.edu>
<Pine.LNX.4.33.0109181122550.9711-100...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0109181122550.9711-100000@penguin.transmeta.com>
User-Agent: Mutt/1.3.20i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Sep 2001 19:17:09 GMT
Message-ID: <fa.enemnqv.1rleaog@ifi.uio.no>
References: <fa.ofabcuv.nks537@ifi.uio.no>
Lines: 35
On Sep 18, 2001 11:27 -0700, Linus Torvalds wrote:
> I agree that the timing may leave something to be desired. But we had the
> discussion about fixing pagecache-bdev consistency wrt the regular buffer
> cache filesystem accesses a week or so ago, and the fact is that nobody
> really seems to have started working on it - because everybody felt that
> you have to get everything done at once.
The real question is why can't we just open 2.5 and only fix the VM to
start with? Leave the kernel at 2.4.10-pre10, and possibly use the -ac
VM code (which has diverged from mainline), and leave people (Alan, Ben,
Marcello, et. al.) who want to tinker with it in small increments and
do the drastic stuff in 2.5.
Make it clear that 2.5 is still ONLY for VM and other bug fixes at this
point, and not all of the long-awaited 2.5 rework YET. If it turns
out that the VM fixes are done quickly, then they can be back-ported
to 2.4. If it takes longer than expected you can open 2.5 up to general
development.
With the right "management" it will be not much different than the current
situation, except that people won't have fits about such huge changes
going into 2.4. I think this is your subconcious telling you that you
really wanted to start 2.5 a month ago.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Tue, 18 Sep 2001 22:17:48 +0200
From: Stephan von Krawczynski <sk...@ithnet.com>
To: Andreas Dilger <adil...@turbolabs.com>
Cc: torva...@transmeta.com, v...@math.psu.edu, linux-ker...@vger.kernel.org
Subject: Re: Linux 2.4.10-pre11
Original-Message-Id: <20010918221748.1f51f801.skraw@ithnet.com>
In-Reply-To: <20010918131419.A14526@turbolinux.com>
Original-References: <Pine.GSO.4.21.0109181354470.27125-100...@weyl.math.psu.edu>
<Pine.LNX.4.33.0109181122550.9711-100...@penguin.transmeta.com>
<20010918131419.A14...@turbolinux.com>
X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: ith Kommunikationstechnik GmbH
Date: Tue, 18 Sep 2001 20:20:27 GMT
Message-ID: <fa.hgi6t4v.1fmu3gp@ifi.uio.no>
References: <fa.enemnqv.1rleaog@ifi.uio.no>
Lines: 44
On Tue, 18 Sep 2001 13:14:19 -0600 Andreas Dilger <adil...@turbolabs.com>
wrote:
> On Sep 18, 2001 11:27 -0700, Linus Torvalds wrote:
> [...]
> The real question is why can't we just open 2.5 and only fix the VM to
> start with?
Hm, I guess if anybody would be capable of _really_ fixing vm in upto-pre10
state, he would have done it already. It's not that people would not have
tried, but it looks like nobody is able to get the _whole_ picture of this.
Surely there are people that know a lot about certain parts of the (old) vm
code, and thats exactly what leads to this Linus' statements here sounding like
"I had a look at part xyz of it and it's a mess. Patch appended." (see pre10 vm
patch).
You have to keep in mind that a lot of people on the planet try to use 2.4 in a
unbelievably broad variety of setups - and quite a number of them relies on
released kernels. If you take a close look at 2.4.7, 2.4.8, 2.4.9 you may well
find out, that they're unusable compared to 2.2.19. You cannot go on like this.
I really do back Andrea and Linus for this step, because I can _see_ a great
win in performance _and_ things got less complex in this code. So there is a
much bigger chance to tilt the last remaining problems in short time (hopefully
before 2.4.10 or .11).
So I guess the right thing to do now is give Andrea good input of leftover,
reproducible problems to give him a chance to fix them. A major discussion
about "doing it all the way round" makes only sense, if someone comes up with
something _at least_ as good as Andrea's code.
Then its "Lonely Linus"' decision to choose. Whatever he will choose, a good
percentage LKML will be against it. This is a normal thing, the guy that has to
make the decision is alone most of the time. The only way for you to find out
if he is right is to _try_ it. If he is, tell him. If he isn't, send a patch.
He couldn't have been that wrong the last years, though.
</end sermon>
Just _one_ opinion from an unimportant guy,
Stephan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Wed, 19 Sep 2001 10:42:07 -0300 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender: <r...@imladris.rielhome.conectiva>
To: Stephan von Krawczynski <sk...@ithnet.com>
Cc: Andreas Dilger <adil...@turbolabs.com>, <torva...@transmeta.com>,
<v...@math.psu.edu>, <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <20010918221748.1f51f801.skraw@ithnet.com>
Original-Message-ID:
<Pine.LNX.4.33L.0109191040370.4279-100000@imladris.rielhome.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 19 Sep 2001 13:43:48 GMT
Message-ID: <fa.pb6tckv.1t2850c@ifi.uio.no>
References: <fa.hgi6t4v.1fmu3gp@ifi.uio.no>
Lines: 33
On Tue, 18 Sep 2001, Stephan von Krawczynski wrote:
> Hm, I guess if anybody would be capable of _really_ fixing vm in
> upto-pre10 state, he would have done it already. It's not that people
> would not have tried, but it looks like nobody is able to get the
> _whole_ picture of this.
Look, the problem is that Linus is being an a**hole and
integrating conflicting ideas into both the VM and the
VFS, without giving anybody prior notice and later blame
others.
Just look at how he's now trying to force Al Viro into
implementing his ideas yesterday because he broke stuff
again...
If you want a stable kernel, use Alan's kernel.
regards,
Rik
--
IA64: a worthy successor to i860.
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardv...@nl.linux.org (spam digging piggy)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newsfeed.media.kyoto-u.ac.jp!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Original-Date: Wed, 19 Sep 2001 10:27:32 -0400 (EDT)
From: Alexander Viro <v...@math.psu.edu>
To: Rik van Riel <r...@conectiva.com.br>
cc: Stephan von Krawczynski <sk...@ithnet.com>,
Andreas Dilger <adil...@turbolabs.com>, torva...@transmeta.com,
linux-ker...@vger.kernel.org
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.33L.0109191040370.4279-100000@imladris.rielhome.conectiva>
Original-Message-ID: <Pine.GSO.4.21.0109190956240.28824-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 19 Sep 2001 14:29:02 GMT
Message-ID: <fa.mgbpu3v.lkcobo@ifi.uio.no>
References: <fa.pb6tckv.1t2850c@ifi.uio.no>
Lines: 31
On Wed, 19 Sep 2001, Rik van Riel wrote:
> Just look at how he's now trying to force Al Viro into
> implementing his ideas yesterday because he broke stuff
> again...
Rik, in case you've missed that, I can and do speak for myself. I had
spent ten years dodging the draft; when I decide to get enlisted into
something it will happen on _my_ decision and _my_ conditions. When I
decide that I'm being forced into something I do not accept - you'll know
it from posting with URL of forked tree.
FWIW, I'm less than thrilled by the Andrea's patch, but it is salvagable.
I'm also less than thrilled by the whole situation with VM - all sides of
it. I seriously suspect that we need a limited multi-way fork in that
area, so that you guys would stop stepping on each others' toes. I'm taking
no part in your merry 5-way clusterfuck - sort that mess out between
yourselves.
Again, when I decide that situation is unacceptable for me - I'll simply
fork the tree. I do _not_ appreciate being enlisted into anyone's holy
wars, so unless you really want to go _way_ up in my personal s***list
(several positions below .ru DoD) - don't play politics in my vicinity.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Original-Date: Wed, 19 Sep 2001 12:11:56 -0400 (EDT)
From: Alexander Viro <v...@math.psu.edu>
To: Linus Torvalds <torva...@transmeta.com>
cc: Andrea Arcangeli <and...@suse.de>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
In-Reply-To: <Pine.LNX.4.33.0109181122550.9711-100000@penguin.transmeta.com>
Original-Message-ID: <Pine.GSO.4.21.0109191205580.28824-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 19 Sep 2001 16:13:13 GMT
Message-ID: <fa.mibjsqv.mk2p3r@ifi.uio.no>
References: <fa.ofabcuv.nks537@ifi.uio.no>
Lines: 26
On Tue, 18 Sep 2001, Linus Torvalds wrote:
>
> On Tue, 18 Sep 2001, Alexander Viro wrote:
> >
> > It can be modified so that combination with lazy-bdev and pipefs-like tree
> > would work. And yes, most of the ugliness would just go away.
>
> That's the part I like about the page-cache bdev patch. It has a lot of
> fairly ugly warts, but all of them seem to be really fixable with _other_
> cleanups, at which point only the good parts remain.
It's actually quite broken in several areas (== bunch of panicable rmmod
races, broken wrt umount(), trivially oopsable in ioctl() on ramdisk,
very suspicious in swapoff(2), etc.). It _might_ be fixable, but I
would really like to see the patch that went into -pre11 separately from
the rest. Andrea, could you send it to me? In particular, I'm deeply
suspicious about changes in blkdev_put() in case of BDEV_FILE.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Wed, 19 Sep 2001 20:25:39 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Alexander Viro <v...@math.psu.edu>
Cc: Linus Torvalds <torva...@transmeta.com>,
Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Original-Message-ID: <20010919202539.E720@athlon.random>
Original-References:
<Pine.LNX.4.33.0109181122550.9711-100...@penguin.transmeta.com>
<Pine.GSO.4.21.0109191205580.28824-100...@weyl.math.psu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0109191205580.28824-100000@weyl.math.psu.edu>;
from viro@math.psu.edu on Wed, Sep 19, 2001 at 12:11:56PM -0400
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 19 Sep 2001 18:27:16 GMT
Message-ID: <fa.g9ssmgv.1i02g28@ifi.uio.no>
References: <fa.mibjsqv.mk2p3r@ifi.uio.no>
Lines: 21
On Wed, Sep 19, 2001 at 12:11:56PM -0400, Alexander Viro wrote:
> the rest. Andrea, could you send it to me? In particular, I'm deeply
> suspicious about changes in blkdev_put() in case of BDEV_FILE.
of course, for the record you can also find it in the ftp area all
splitted out, but I've no problem to send it via email too.
Quite frankly the BDEV_* handling was and is a total mess IMHO, even if
it was written by you ;), there was no difference at all from many of
them, I didn't fixed that but I had to check all them on the differences
until I realized there was none. I also think the other things you
mentioned (besides the inode pinning bug, non critical) are not buggy
(infact I never had a single report), but well we'll verify that in
detail ASAP.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.home.com!gehenna.pell.portland.or.us!nntp-server.caltech.edu!
nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: Tue, 18 Sep 2001 17:39:30 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: Linux 2.4.10-pre12
Message-ID: <linux.kernel.Pine.LNX.4.33.0109181737550.1111-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 146
Lots more merging - it almost looks like there's a light at the end of the
tunnel.
VM tweaks, notably OOM handling.
And a nasty ptrace bug fixed.
Linus
------
pre12:
- Alan Cox: much more merging
- Pete Zaitcev: ymfpci race fixes
- Andrea Arkangeli: VM race fix and OOM tweak.
- Arjan Van de Ven: merge RH kernel fixes
- Andi Kleen: use more readable 'likely()/unlikely()' instead of __builtin_expect()
- Keith Owens: fix 64-bit ELF types
- Gerd Knorr: mark more broken PCI bridges, update btaudio driver
- Paul Mackerras: powermac driver update
- me: clean up PTRACE_DETACH to use common infrastructure
pre11:
- Neil Brown: md cleanups/fixes
- Andrew Morton: console locking merge
- Andrea Arkangeli: major VM merge
pre10:
- Alan Cox: continued merging
- Mingming Cao: make msgrcv/shmat check the queue/segment ID's properly
- Greg KH: USB serial init failure fix, Xircom serial converter driver
- Neil Brown: nsfd/raid/md/lockd cleanups
- Ingo Molnar: multipath RAID personality, raid xor update
- Hugh Dickins/Marcelo Tosatti: swapin read-ahead race fix
- Vojtech Pavlik: fix up some of the infrastructure for x86-64
- Robert Love: AMD 761 AGP GART support
- Jens Axboe: fix SCSI-generic queue handling race
- me: be sane about page reference bits
pre9:
- Greg KH: start migration to new "min()/max()"
- Roman Zippel: move affs over to "min()/max()".
- Vojtech Pavlik: VIA update (make sure not to IRQ-unmask a vt82c576)
- Jan Kara: quota bug-fix (don't decrement quota for non-counted inode)
- Anton Altaparmakov: more NTFS updates
- Al Viro: make nosuid/noexec/nodev be per-mount flags, not per-filesystem
- Alan Cox: merge input/joystick layer differences, driver and alpha merge
- Keith Owens: scsi Makefile cleanup
- Trond Myklebust: fix oopsable race in locking code
- Jean Tourrilhes: IrDA update
pre8:
- Christoph Hellwig: clean up personality handling a bit
- Robert Love: update sysctl/vm documentation
- make the three-argument (that everybody hates) "min()" be "min_t()",
and introduce a type-anal "min()" that complains about arguments of
different types.
pre7:
- Alan Cox: big driver/mips sync
- Andries Brouwer, Christoph Hellwig: more gendisk fixups
- Tobias Ringstrom: tulip driver workaround for DC21143 erratum
pre6:
- Jens Axboe: remove trivially dead io_request_lock usage
- Andrea Arcangeli: softirq cleanup and ARM fixes. Slab cleanups
- Christoph Hellwig: gendisk handling helper functions/cleanups
- Nikita Danilov: reiserfs dead code pruning
- Anton Altaparmakov: NTFS update to 1.1.18
- firestream network driver: patch reverted on authors request
- NIIBE Yutaka: SH architecture update
- Paul Mackerras: PPC cleanups, PPC8xx update.
- me: reverse broken bootdata allocation patch that went into pre5
pre5:
- Merge with Alan
- Trond Myklebust: NFS fixes - kmap and root inode special case
- Al Viro: more superblock cleanups, inode leak in rd.c, minix
directories in page cache
- Paul Mackerras: clean up rubbish from sl82c105.c
- Neil Brown: md/raid cleanups, NFS filehandles
- Johannes Erdfelt: USB update (usb-2.0 support, visor fix, Clie fix,
pl2303 driver update)
- David Miller: sparc and net update
- Eric Biederman: simplify and correct bootdata allocation - don't
overwrite ramdisks
- Tim Waugh: support multiple SuperIO devices, parport doc updates
pre4:
- Hugh Dickins: swapoff cleanups and speedups
- Matthew Dharm: USB storage update
- Keith Owens: Makefile fixes
- Tom Rini: MPC8xx build fix
- Nikita Danilov: reiserfs update
- Jakub Jelinek: ELF loader fix for ET_DYN
- Andrew Morton: reparent_to_init() for kernel threads
- Christoph Hellwig: VxFS and SysV updates, vfs_permission fix
pre3:
- Johannes Erdfelt, Oliver Neukum: USB printer driver race fix
- John Byrne: fix stupid i386-SMP irq stack layout bug
- Andreas Bombe, me: yenta IO window fix
- Neil Brown: raid1 buffer state fix
- David Miller, Paul Mackerras: fix up sparc and ppc respectively for kmap/kbd_rate
- Matija Nalis: umsdos fixes, and make it possible to boot up with umsdos
- Francois Romieu: fix bugs in dscc4 driver
- Andy Grover: new PCI config space access functions (eventually for ACPI)
- Albert Cranford: fix incorrect e2fsprog data from ver_linux script
- Dave Jones: re-sync x86 setup code, fix macsonic kmalloc use
- Johannes Erdfelt: remove obsolete plusb USB driver
- Andries Brouwer: fix USB compact flash version info, add blksize ioctls
pre2:
- Al Viro: block device cleanups
- Marcelo Tosatti: make bounce buffer allocations more robust (it's ok
for them to do IO, just not cause recursive bounce IO. So allow them)
- Anton Altaparmakov: NTFS update (1.1.17)
- Paul Mackerras: PPC update (big re-org)
- Petko Manolov: USB pegasus driver fixes
- David Miller: networking and sparc updates
- Trond Myklebust: Export atomic_dec_and_lock
- OGAWA Hirofumi: find and fix umsdos "filldir" users that were broken
by the 64-bit-cleanups. Fix msdos warnings.
- Al Viro: superblock handling cleanups and race fixes
- Johannes Erdfelt++: USB updates
pre1:
- Jeff Hartmann: DRM AGP/alpha cleanups
- Ben LaHaise: highmem user pagecopy/clear optimization
- Vojtech Pavlik: VIA IDE driver update
- Herbert Xu: make cramfs work with HIGHMEM pages
- David Fennell: awe32 ram size detection improvement
- Istvan Varadi: umsdos EMD filename bug fix
- Keith Owens: make min/max work for pointers too
- Jan Kara: quota initialization fix
- Brad Hards: Kaweth USB driver update (enable, and fix endianness)
- Ralf Baechle: MIPS updates
- David Gibson: airport driver update
- Rogier Wolff: firestream ATM driver multi-phy support
- Daniel Phillips: swap read page referenced set - avoid swap thrashing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/