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: 2.4.10 much better than previous 2.4.x :-)
From: Michael Rothwell <rothw...@holly-springs.nc.us>
X-To: lkml <linux-ker...@vger.kernel.org>
Content-Type: text/plain
Date: 24 Sep 2001 20:29:44 -0400
Message-ID: <linux.kernel.1001377785.1430.7.camel@gromit.house>
Mime-Version: 1.0
Approved: n...@nntp-server.caltech.edu
Lines: 16
This is mainly a thank you for 2.4.10. It performs much better than
2.4.7 (RedHat version), from which I upgraded. Interactive performance
for applications (Gnome, Evolution, Mozilla) is much improved, and my
swap load is at zero, which is probably where it should be (2.4.7 would
regularly be using 256MB of swap with the same applications running).
Thanks!
--Michael
-
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: Mon, 24 Sep 2001 22:35:53 -0300 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-To: Michael Rothwell <rothw...@holly-springs.nc.us>
X-Cc: lkml <linux-ker...@vger.kernel.org>
Subject: Re: 2.4.10 much better than previous 2.4.x :-)
Message-ID:
<linux.kernel.Pine.LNX.4.33L.0109242234410.19147-100000@imladris.rielhome.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 28
On 24 Sep 2001, Michael Rothwell wrote:
> This is mainly a thank you for 2.4.10. It performs much better than
> 2.4.7 (RedHat version), from which I upgraded. Interactive performance
> for applications (Gnome, Evolution, Mozilla) is much improved,
If you have the time, could you also test 2.4.9-ac15 ?
(The -ac VM has basically branched off at 2.4.7 and has
evolved quite a bit since ... last week I fixed a stupid
page aging bug and things should be a lot better than
before now)
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!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
Message-ID: <linux.kernel.3BB0AE43.BC36820F@TeraPort.de>
Date: Tue, 25 Sep 2001 18:18:11 +0200
From: Martin Knoblauch <Martin.Knobla...@TeraPort.de>
Organization: TeraPort GmbH
MIME-Version: 1.0
X-To: "linux-ker...@vger.kernel.org" <linux-ker...@vger.kernel.org>
X-CC: r...@conectiva.com.br
Subject: Re: 2.4.10 much better than previous 2.4.x :-)
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 50
> Re: 2.4.10 much better than previous 2.4.x :-)
>
>
> On 24 Sep 2001, Michael Rothwell wrote:
>
> > This is mainly a thank you for 2.4.10. It performs much better than
> > 2.4.7 (RedHat version), from which I upgraded. Interactive performance
> > for applications (Gnome, Evolution, Mozilla) is much improved,
>
> If you have the time, could you also test 2.4.9-ac15 ?
>
> (The -ac VM has basically branched off at 2.4.7 and has
> evolved quite a bit since ... last week I fixed a stupid
> page aging bug and things should be a lot better than
> before now)
>
> regards,
>
> Rik
>
Rik,
just did a short test with both 2.4.9-ac15 and 2.4.10 plain on a
Notebook with 320 MB and twice as much swap. "/" is on reiserfs.
Both look a lot better that anything before. With my workload of
netscape, NT_under_vmware (128 MB memory) and a kernel compile I am not
using swap for the first time since in 2.4.x.
My feeling is that 2.4.10 behaves a bit better with high I/O activity
on the reiserfs partition. Maybe this can be attributed to the latest
reiserfs stuff that went into 2.4.10, but not yet in -ac. The
responsiveness when "suspending" the vmware session has definitely
improved with 2.4.10. With 2.4.9-ac the system "freezes" for some
seconds during that operation.
In any case, good work in both trees.
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: Martin.Knobla...@TeraPort.de
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
-
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!news2.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: Wed, 26 Sep 2001 02:06:17 +0200
From: Andrea Arcangeli <and...@suse.de>
X-To: Michael Rothwell <rothw...@holly-springs.nc.us>
X-Cc: lkml <linux-ker...@vger.kernel.org>
Subject: Re: 2.4.10 much better than previous 2.4.x :-)
Message-ID: <linux.kernel.20010926020617.T1782@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 16
On Mon, Sep 24, 2001 at 08:29:44PM -0400, Michael Rothwell wrote:
>
> This is mainly a thank you for 2.4.10. It performs much better than
> 2.4.7 (RedHat version), from which I upgraded. Interactive performance
> for applications (Gnome, Evolution, Mozilla) is much improved, and my
> swap load is at zero, which is probably where it should be (2.4.7 would
> regularly be using 256MB of swap with the same applications running).
if you apply vm-tweaks-1 it should get even better ;).
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, 25 Sep 2001 20:35:15 -0400
From: Paul <s...@pobox.com>
X-To: Rik van Riel <r...@conectiva.com.br>
X-Cc: lkml <linux-ker...@vger.kernel.org>
Subject: Re: 2.4.10 much better than previous 2.4.x :-)
Message-ID: <linux.kernel.20010925203515.A227@squish.home.loc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 67
Rik van Riel <r...@conectiva.com.br>, on Mon Sep 24, 2001 [10:35:53 PM] said:
>
> If you have the time, could you also test 2.4.9-ac15 ?
>
> (The -ac VM has basically branched off at 2.4.7 and has
> evolved quite a bit since ... last week I fixed a stupid
> page aging bug and things should be a lot better than
> before now)
>
> regards,
>
> Rik
K6-333 128M ram
2.4.9-ac15 my impression: Well, running mutt with 80M
folder open, desktop with several aterms and netscape with a few
windows open, I started building a kernel in one term, and a
'find / -type f -exec md5sum {}' in another, then started reading
the mail, and occasionally jumping around the virtual desktop,
exposing netscapes... (this is pretty much my normal working
load, except for the find.)
I thought it worked very well; exposed netscapes were
either just there, or drew almost instantly. (other kernels I
have used, under the same load would usually take quite a bit
longer for exposed netscape to draw itself.) 'interactiveness'
seemed good.
Then, I read a post in this thread about swap being
funny. I noticed that no swap was being reported as used all
during my test. So, I forced the issue with an endless malloc.
Very quickly, the system seems to freeze, and the disk is
yammering away. I was waiting for the OOM killer to kick in,
but it never did. <alt><sysrq> works well, and I used it to print
out the Mem stats after several minutes. Eventually, I used
sysrq to sync and kill (couldnt get it to reBoot, though).
Im not complaining-- Im just curious why no OOM killing,
and the Mem stats report 337148k swap free (I have 337168k).
Does this memmory report look proper for a machine thrashing
itself to death from endless mallocs?
Paul
s...@pobox.com
SysRq : Show Memory
Mem-info:
Free pages: 1512kB ( 0kB HighMem)
( Active: 63, inactive_dirty: 172, inactive_clean: 0, free: 378 (351 702 1053) )
1*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB = 508kB)
25*4kB 3*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB = 1004kB)
= 0kB)
Swap cache: add 5, delete 5, find 0/0
Page cache size: 79
Buffer mem: 156
Ramdisk pages: 0
Free swap: 337148kB
32764 pages of RAM
0 pages of HIGHMEM
1038 reserved pages
115 pages shared
0 pages swap cached
0 pages in page table cache
Buffer memory: 624kB
-
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!news2.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: Wed, 26 Sep 2001 20:08:33 +0000
From: =?iso-8859-1?Q?Jos=E9_Luis_Domingo_L=F3pez?=
<jdomi...@internautas.org>
X-To: lkml <linux-ker...@vger.kernel.org>
X-Cc: Paul <s...@pobox.com>, Rik van Riel <r...@conectiva.com.br>
Subject: Re: 2.4.10 much better than previous 2.4.x :-)
Message-ID: <linux.kernel.20010926200833.A1859@dardhal.mired.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Approved: n...@nntp-server.caltech.edu
Lines: 56
On Tuesday, 25 September 2001, at 20:35:15 -0400,
Paul wrote:
> Rik van Riel <r...@conectiva.com.br>, on Mon Sep 24, 2001 [10:35:53 PM] said:
> >
> > If you have the time, could you also test 2.4.9-ac15 ?
> > [...]
> Im not complaining-- Im just curious why no OOM killing,
> and the Mem stats report 337148k swap free (I have 337168k).
> Does this memmory report look proper for a machine thrashing
> itself to death from endless mallocs?
>
I've done several test with various versions of 2.4.x kernels, just to
make sure OOM worked right or not. I've used setups with both swap and no
swap, with swap double the RAM and equal to it, from a single user mode
and full multiuser with tons of applications running.
To reach OOM I try one of two methods: first, the well-know glob() DoS
(ls ../*/../*/../*/ etc), second, starting as many applications as I can,
loading and creating huge images with gimp, etc.
In my test, OOM seems to work well most of the time, but not always. When
in works, it works fine, that is, it doesn't kill applications too early,
and (in recent kernel), multithreaded applications (like mozilla and
staroffice) and fully wiped from memory ("old" 2.4.x kernels didn't kill
all the threads, just the selected process ID).
When OOM doesn't work, the disk starts spinning like crazy, responsiveness
in null, mouse doesn't move, consoles don't update, unability to switch to
text consoles, etc. Giving time to the machine to recover itself is not
helpful: after more than 15 minutes the disk continue to spin and sound
like they were to inmediately crash :)
But in this situation, SysRq+K work fine most of the times: in a couple of
seconds the disk stops its crazyness, and the machine recovers. The text
console is unusable (can't display a thing), but issuing a "startx"
blindly works as expected, as if nothing had happened.
I've tried playing with "freepages" tunnable (where it exists), to raise
limits and (hopefully) keep more RAM free for the kernel for the hard
times where it tries to recover from OOM. OOM still fails sometimes, but
maybe I don't understand what freepages.[min|low|high] mean (having read
documentation under linux/Documentation :)
--
José Luis Domingo López
Linux Registered User #189436 Debian Linux Woody (P166 64 MB RAM)
jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk
-
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>
Subject: 2.4.10 swap behaviour
From: Osma Ahvenlampi <o...@iki.fi>
To: linux-ker...@vger.kernel.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.14.99+cvs.2001.09.22.08.08 (Preview Release)
Original-Date: 26 Sep 2001 10:41:48 +0300
Original-Message-Id: <1001490108.1444.34.camel@136.quartal.com>
Mime-Version: 1.0
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Wed, 26 Sep 2001 07:43:29 GMT
Message-ID: <fa.fj5ss3v.j4860k@ifi.uio.no>
Lines: 63
Cheers,
Yesterday, after upgrading to 2.4.10 and deciding it was significantly
better about memory usage under light load than 2.4.9, I ran a
pathological test case with rather interesting results..
My machine is a 900MHz P3 laptop with 512MB of memory (just upgraded
from 256M - most of my experience with earlier 2.4 kernels up to 2.4.9
is with 256M, which adds some variability into the subjective
experience..). I ran these tests with a vanilla 2.4.9 kernel and 2.4.10
patched with Robert Love's 2.4.10-preempt patches.
Under both kernels, I ran a simulated medium-load session (Ximian Gnome,
Evolution, a Java server, XEmacs and a 128MB VMware session open but not
particularly active, no net connection), and then started a cat /dev/dvd
>/dev/null process, watching the memory usage pattern with vmstat and
free. Before the cat, I had about 190 megs of memory used (disregarding
buffers/cache) - the VMware session had not allocated all of it's 128MB
limit, remaining around 80 megs at the point.
2.4.9 would gradually increase its buffer and cache memory until were
around 150-200 megs. At this point, a lot of the applications had been
swapped out, with 60 megs of swap in use, and the system was very
sluggish. I aborted the cat with a ctrl-c and the system regained
responsiveness fairly quickly (paging heavily until most code was back
in).
2.4.10 remained more responsive in the beginning, and I noticed that the
buffer allocation would actually drop from the initial 15 megs to under
5. However, the cache usage kept on going up, until about 440 megs of
RAM was used by the cache (and less than a meg in buffers!). At this
point, about 90 megs of swap had been allocated, and the machine quite
quickly lost all response. The mouse pointer would not move, the active
terminal window showed no response to keyboard, I could not switch to
another VC. Except for the constant disk access, the machine might as
well been completely hung, and for a moment I thought it was. Eventually
I was forced to eject the entire DVD drive from the machine (good thing
I was testing on a laptop! :)), at which point the cat process obviously
would be aborted. After that, it took about 20-30 seconds until the
terminal started to respond (slowly), and a couple of minutes before the
all the applications were again usable (after heavy paging again,
obviously).
Conclusion: 2.4.10 buffer behaviour is dramatically different, and the
system remains responsive somewhat longer under medium load - some of
that might be attributed to the preempt patches, however. Under heavy
sequential IO load, the cache still has a pathological behaviour of
forcing everything else out of memory, which can make the system act as
if completely dead, unless the IO process can be aborted. The improved
behaviour under moderate load makes the transition from "paging but
decent" to "completely unusable" somewhat delayed but more sudden when
it does happen.
let me know if you want me to test something different..
--
Osma Ahvenlampi <o...@iki.fi>
-
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, 26 Sep 2001 15:42:25 +0200
From: Andrea Arcangeli <and...@suse.de>
To: Osma Ahvenlampi <o...@iki.fi>
Cc: linux-ker...@vger.kernel.org, Linus Torvalds <torva...@transmeta.com>
Subject: Re: 2.4.10 swap behaviour (with vm-tweaks-2)
Original-Message-ID: <20010926154225.D27945@athlon.random>
Original-References: <1001490108.1444.34.ca...@136.quartal.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1001490108.1444.34.camel@136.quartal.com>;
from oa@iki.fi on Wed, Sep 26, 2001 at 10:41:48AM +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: Wed, 26 Sep 2001 13:46:57 GMT
Message-ID: <fa.eajk4mv.1lgssbm@ifi.uio.no>
References: <fa.fj5ss3v.j4860k@ifi.uio.no>
Lines: 180
On Wed, Sep 26, 2001 at 10:41:48AM +0300, Osma Ahvenlampi wrote:
> quickly lost all response. The mouse pointer would not move, the active
You really want to apply vm-tweaks-1, (or better vm-tweaks-2 inlined
here with the bugfix for Cary's div by zero, woops) and try again. It
applies cleanly to vanilla 2.4.10.
Linus I'd suggest for inclusion, I know you hate it but think at least
at the huge benefit in light vm-pressure load when just heavy non-mapped
cache pollution is going on, even if you disagree about the
pageout-trigger condition (but swapout behaviour is much better too this
way, and I disagree in constantly wasting cpu to know when to swap
anyways).
(btw, after this patch we can also drop the "survive" cruft into the
page fault handler, not included here since not very important cleanup)
Patch
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>
Subject: Re: 2.4.10 swap behaviour (with vm-tweaks-2)
From: Osma Ahvenlampi <o...@iki.fi>
To: Andrea Arcangeli <and...@suse.de>
Cc: linux-ker...@vger.kernel.org, Linus Torvalds <torva...@transmeta.com>
In-Reply-To: <20010926154225.D27945@athlon.random>
Original-References: <1001490108.1444.34.ca...@136.quartal.com>
<20010926154225.D27...@athlon.random>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.14.99+cvs.2001.09.22.08.08 (Preview Release)
Original-Date: 27 Sep 2001 12:32:14 +0300
Original-Message-Id: <1001583134.1895.96.camel@136.quartal.com>
Mime-Version: 1.0
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Sep 2001 09:34:12 GMT
Message-ID: <fa.fq60t3v.h4c6gk@ifi.uio.no>
References: <fa.eajk4mv.1lgssbm@ifi.uio.no>
Lines: 40
Thanks Andrea,
after applying the patch, I repeated the experiment. Since the cat
/dev/dvd >/dev/null no longer really made any difference, I started at
the same time a dd if=/dev/hda2 of=/dev/null (a 6 GB partition) and
eight find / processes at slightly difference points in time (to
excercise the same disk blocks repeatedly). I let the whole thing run
for about 5 times longer than the original test, and while the system
still pushed a lot of programs onto swap (from an initial used memory of
190 megs, up to 80 was pushed onto swap while I kept "using" most of the
programs by clicking on buttons etc), the system remained fairly
responsive (a couple of individual apps became sluggish enough to
categorize as unresponsive, but a couple of other programs kept
responding almost as well as in a no-load condition). To top it off, I
tried to play some .ogg files with XMMS - there were breakups in the
output every 10-15 seconds, but other than that, XMMS worked fine as
well. I don't run XMMS with realtime priority, so that might have fixed
even the sound output problems.
I'd have to say I now (finally!) have a kernel which doesn't eat up all
my memory.. :) For the record, the setup now is 2.4.10 +
rml-preempt-kernel-1 + aa-vm-tweaks-2.
Cheers,
Osma
On Wed, 2001-09-26 at 16:42, Andrea Arcangeli wrote:
> You really want to apply vm-tweaks-1, (or better vm-tweaks-2 inlined
> here with the bugfix for Cary's div by zero, woops) and try again. It
> applies cleanly to vanilla 2.4.10.
--
Osma Ahvenlampi <o...@iki.fi>
-
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!news1.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: Sat, 29 Sep 2001 18:19:13 +0200 (CEST)
From: Tobias Ringstrom <t...@ringstrom.mine.nu>
X-X-Sender: <t...@boris.prodako.se>
To: Kernel Mailing List <linux-ker...@vger.kernel.org>
Subject: 2.4.10 VM, active cache pages, and OOM
Original-Message-ID: <Pine.LNX.4.33.0109291645260.16885-100000@boris.prodako.se>
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: Sat, 29 Sep 2001 16:22:34 GMT
Message-ID: <fa.lm7rq5v.1hnmt9k@ifi.uio.no>
Lines: 65
First I'd like to say that the 2.4.10 VM works great for my desktop and
home server, much better than previous versions. I have not tried Alan's
kernels.
I do have one problem, though, and it is illustrated by the following very
simple program:
#include <unistd.h>
int main()
{
char buf[512];
while (read(0, buf, sizeof(buf)) == sizeof(buf))
;
return 0;
}
The program should be reading a block device, but a big file probably does
the trick as well.
./a.out < /dev/hde1
When the program is running, all cached pages pop up in the active list,
and when the memory is full of active pages, the computer starts to page
out stuff, becomes VERY unresponsive, and after half a minute or so it
goes OOM and starts killing processes. There are lots and lots of free
swap at this time. I also get a bunch of 0-order allocation failures in
the log.
(I'd say that the OOM killer does seem to kill the most memory-hog-like
processes, but the problem is that it is not the processes that use up all
the memory, it is the active cache pages.)
If the buf size is changed to a multiple of the page size, such as 4096,
the cache pages are instead added to the inactive list, and the system is
very responsive, no paging occurs, and it does not go OOM. In other
words, it works perfectly.
I assume that the difference between a buf size of 512 and 4096 is that
for the 512-byte case, each page is touched more than once, and that's why
the system think the pages are active. This is a very wrong decision,
since I'm doing a sequential read.
Fixing that particular problem will get rid of my problem, but I'm
guessing that it would only hide another real problem, which is that
2.4.10 has a huge problem freeing pages from the list of active pages,
even if they are clean, and thus making a wrong decision on the
availibility of free(able) pages.
Am I right to assume that if I would make the program do random seeks, or
read each page twice, the pages would again be added to the active list,
even if I would read whole pages at a time?
I also wonder why the system get so unresponsive before it goes OOM.
Perhaps there is a kernel process running, scanning lists trying to free
memory, but not finding any, wasting all CPU cycles.
What do you think?
/Tobias
-
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!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!skynet.be!skynet.be!news.algonet.se!
algonet!newsfeed1.uni2.dk!news.net.uni-c.dk!uninett.no!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: palladium.transmeta.com: mail set sender to n...@transmeta.com using -f
To: linux-ker...@vger.kernel.org
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: 2.4.10 VM, active cache pages, and OOM
Original-Date: Sat, 29 Sep 2001 18:36:50 +0000 (UTC)
Original-Message-ID: <9p54c2$836$1@penguin.transmeta.com>
Original-References: <Pine.LNX.4.33.0109291645260.16885-100...@boris.prodako.se>
X-Complaints-To: news@transmeta.com
Original-NNTP-Posting-Date: 29 Sep 2001 18:37:03 GMT
Cache-Post-Path: palladium.transmeta.com!unkn...@penguin.transmeta.com
X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/)
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Transmeta Corporation
Date: Sat, 29 Sep 2001 18:38:49 GMT
Message-ID: <fa.icejkov.a2gjol@ifi.uio.no>
References: <fa.lm7rq5v.1hnmt9k@ifi.uio.no>
Lines: 81
In article <Pine.LNX.4.33.0109291645260.16885-100...@boris.prodako.se>,
Tobias Ringstrom <t...@ringstrom.mine.nu> wrote:
>
>I assume that the difference between a buf size of 512 and 4096 is that
>for the 512-byte case, each page is touched more than once, and that's why
>the system think the pages are active. This is a very wrong decision,
>since I'm doing a sequential read.
>
>Fixing that particular problem will get rid of my problem, but I'm
>guessing that it would only hide another real problem, which is that
>2.4.10 has a huge problem freeing pages from the list of active pages,
>even if they are clean, and thus making a wrong decision on the
>availibility of free(able) pages.
Absolutely right.
It's probably worth fixing the "sequential accesses of < pagesize count
as 'active'" problem too, but the real issue is that if you get into a
situation with _many_ more active pages than inactive, the plain 2.4.10
VM doesn't age the active list nearly fast enough.
That's fixed in Andrea's VM tweaks, but if you want to look into this,
the basic problem is in mm/vmscan.c, shrink_caches(), which in plain
2.4.10 does
/* Do we want to age the active list? */
if (nr_inactive_pages < nr_active_pages*2)
refill_inactive(nr_pages);
which doesn't take into account just _how_ imbalanced the active list
is. So if the active list is huge, it will still just scan a small fixed
percentage of it (and to make matters worse, the small part of it is
proportional to the size of the _inactive_ list, so if the inactive list
is small, that just makes the problem worse.
What Andreas fix does is to make the refill rate be proportional to the
sizes of the lists, which should fix this problem for you.
However, I'd also like to fix generic_file_read() to only mark the page
accessed when we're touching it for the first time, and notice
sequential accesses automatically. That way the use-once logic doesn't
depend on the read size - which is a totally independent problem.
If you want to test, the fix for _that_ is in mm/filemap.c:
do_generic_file_read(), where the code does:
...
ret = actor(desc, page, offset, nr);
offset += ret;
index += offset >> PAGE_CACHE_SHIFT;
offset &= ~PAGE_CACHE_MASK;
mark_page_accessed(page);
...
and it would be interesting to hear if the behaviour improves with the
above mark_page_accessed() logic moved a bit and changed to:
...
ret = actor(desc, page, offset, nr);
if (!offset || !file->f_reada)
mark_page_accessed(page);
offset += ret;
index += offset >> PAGE_CACHE_SHIFT;
offset &= ~PAGE_CACHE_MASK;
...
(which basically says: we only mark the page accessed if we read the
_beginning_ of the page, or if we just did a seek to it)
Btw, if you test the above change out and confirm that it fixes te
behaviour, please send me an acknowledgement email - I've not done it in
my own tree yet, and unless I get a "yes, that works well" email I won't
be doing it..
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!news1.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: Sat, 29 Sep 2001 15:46:50 -0300 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender: <r...@imladris.rielhome.conectiva>
To: Linus Torvalds <torva...@transmeta.com>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: 2.4.10 VM, active cache pages, and OOM
In-Reply-To: <9p54c2$836$1@penguin.transmeta.com>
Original-Message-ID: <Pine.LNX.4.33L.0109291545570.19147-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: Sat, 29 Sep 2001 18:52:12 GMT
Message-ID: <fa.q7aiptv.1q5in81@ifi.uio.no>
References: <fa.icejkov.a2gjol@ifi.uio.no>
Lines: 21
On Sat, 29 Sep 2001, Linus Torvalds wrote:
> (which basically says: we only mark the page accessed if we read the
> _beginning_ of the page, or if we just did a seek to it)
That should work for linear IO, but I fear what influence
such a thing would have on eg. database indexes ;)
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!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!148.122.208.68!news2.oke.nextra.no!
nextra.com!uninett.no!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: Sat, 29 Sep 2001 12:21:07 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
To: Rik van Riel <r...@conectiva.com.br>
cc: <linux-ker...@vger.kernel.org>
Subject: Re: 2.4.10 VM, active cache pages, and OOM
In-Reply-To: <Pine.LNX.4.33L.0109291545570.19147-100000@imladris.rielhome.conectiva>
Original-Message-ID: <Pine.LNX.4.33.0109291219240.8343-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: Sat, 29 Sep 2001 19:31:42 GMT
Message-ID: <fa.oda3dnv.kkg4bf@ifi.uio.no>
References: <fa.q7aiptv.1q5in81@ifi.uio.no>
Lines: 25
On Sat, 29 Sep 2001, Rik van Riel wrote:
> On Sat, 29 Sep 2001, Linus Torvalds wrote:
>
> > (which basically says: we only mark the page accessed if we read the
> > _beginning_ of the page, or if we just did a seek to it)
>
> That should work for linear IO, but I fear what influence
> such a thing would have on eg. database indexes ;)
Well, for things that seek, the behaviour will be the same as it was
before: it will always mark the page accessed, because "file->f_reada"
will always be zero for the first read after a lseek.
That's why we have the "or if we just did a seek to it". You cannot _just_
test for "did we read the beginning of a page", because that fails for
seekers, whether database or otherwise.
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!news1.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>
Original-Date: Sat, 29 Sep 2001 21:43:04 +0200 (CEST)
From: Tobias Ringstrom <t...@ringstrom.mine.nu>
X-X-Sender: <t...@boris.prodako.se>
To: Linus Torvalds <torva...@transmeta.com>
cc: <linux-ker...@vger.kernel.org>
Subject: Re: 2.4.10 VM, active cache pages, and OOM
In-Reply-To: <9p54c2$836$1@penguin.transmeta.com>
Original-Message-ID: <Pine.LNX.4.33.0109292135200.17290-100000@boris.prodako.se>
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: Sat, 29 Sep 2001 19:46:49 GMT
Message-ID: <fa.lk77odv.1inmu1l@ifi.uio.no>
References: <fa.icejkov.a2gjol@ifi.uio.no>
Lines: 53
On Sat, 29 Sep 2001, Linus Torvalds wrote:
> However, I'd also like to fix generic_file_read() to only mark the page
> accessed when we're touching it for the first time, and notice
> sequential accesses automatically. That way the use-once logic doesn't
> depend on the read size - which is a totally independent problem.
>
> If you want to test, the fix for _that_ is in mm/filemap.c:
> do_generic_file_read(), where the code does:
>
> ...
> ret = actor(desc, page, offset, nr);
> offset += ret;
> index += offset >> PAGE_CACHE_SHIFT;
> offset &= ~PAGE_CACHE_MASK;
>
> mark_page_accessed(page);
> ...
>
> and it would be interesting to hear if the behaviour improves with the
> above mark_page_accessed() logic moved a bit and changed to:
>
> ...
> ret = actor(desc, page, offset, nr);
> if (!offset || !file->f_reada)
> mark_page_accessed(page);
> offset += ret;
> index += offset >> PAGE_CACHE_SHIFT;
> offset &= ~PAGE_CACHE_MASK;
> ...
>
> (which basically says: we only mark the page accessed if we read the
> _beginning_ of the page, or if we just did a seek to it)
>
> Btw, if you test the above change out and confirm that it fixes te
> behaviour, please send me an acknowledgement email - I've not done it in
> my own tree yet, and unless I get a "yes, that works well" email I won't
> be doing it..
Yes, that works well, and I tried with a block sizes of 1, 512, 4095 and
4096. The cache pages are not beeing activated now. When reading the
same buf twice with a seek between the reads, the pages are activated, as
expected.
I'll have a look at the other problem, and Andrea's solution, later.
/Tobias
-
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!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news1.ebone.net!news.ebone.net!
news.net.uni-c.dk!uninett.no!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: Thu, 4 Oct 2001 22:57:09 +0200
From: Andrea Arcangeli <and...@suse.de>
To: linux-ker...@vger.kernel.org
Subject: 2.4.11pre3aa1
Original-Message-ID: <20011004225708.A724@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: Thu, 4 Oct 2001 20:58:42 GMT
Message-ID: <fa.g8sco0v.1j0mgi3@ifi.uio.no>
Lines: 536
FYI: the next things I will try to concentrate on the next days are:
1) get_swap_entry collecting exclusive swapcache pages
2) Hugh's locking cleanups
3) Marcelo's vm patches
4) rcu, Dipankar, could you send me your latest version, the design that we
agreed that only adds a per-cpu sequence number inc (not a branch)
in schedule?
5) listening to the softirq patches, still I'd be curious to see the raw
number with only the deschedule logic, just too see the order of
magnitude of overhead caused by the suprious rescheduling, yes when
there's no softirq pending a ksoftirqd reschedule is _literally_ suprious
Thanks to all but especially to Linus and Al for fixing up the aliasing
issues introduced with the blkdev-pagecache during pre[123]! I wouldn't
been able to cover everything myself in such a short timeframe, so I
really appreciated that.
Only in 2.4.11pre3aa1: 00_backout-2.4.11pre1-1
Resurrect some bit like O_DIRECT and drop the fragile vm_swap_full
logic, the plan is to make get_swap_page able to collect exclusive swap
cache pages. Hugh's patches are pending, they changes locking so they're
not included until I'll check them in detail.
Only in 2.4.11pre3aa1: 00_binfmt-elf-checks-1
Rest of the missing checks.
Only in 2.4.10aa1: 00_enable-apic-1
Dropped.
Only in 2.4.11pre3aa1: 00_highmem-deadlock-1
Finegrined highmem deadlock fix, now if we go creating bounce buffers
while we locked down buffers that aren't in the I/O queue yet, we
set the pending_io bitflag on those locked buffers to make sure we
won't deadlock on them while allocating the bounce pages.
Only in 2.4.10aa1: 00_lvm-1.0.1-rc2-2.bz2
Only in 2.4.11pre3aa1: 00_lvm-1.0.1-rc4-1.bz2
Only in 2.4.11pre3aa1: 10_lvm-incremental-1
Picked last update from www.sistina.com and extracted the incremental
changes into a separate patch to make easier furture merging.
Only in 2.4.11pre3aa1: 00_netconsole-2.4.10-C2
Only in 2.4.10aa1: 00_netconsole-code-1
Only in 2.4.10aa1: 00_netconsole-misc-1
Upgrade to -C2 from www.redhat.com/~mingo/ .
Only in 2.4.11pre3aa1: 00_o_direct-1
O_DIRECT updates after the blkdev physical address space fixes.
Only in 2.4.10aa1: 00_rwsem-fair-20-recursive-2
Only in 2.4.11pre3aa1: 00_rwsem-fair-20-recursive-4
Rediffed, and fixed ppc compilation.
Only in 2.4.11pre3aa1: 00_spinlock-cacheline-1
Cacheline align a few critical spinlocks from Juergen Doelle.
Only in 2.4.11pre3aa1: 00_tcp-nagle-1
nagle TCP/IP fixes extracted from the TUX patch downloadable at
www.redhat.com/~mingo/ .
Only in 2.4.10aa1: 00_vm-tweaks-1
Only in 2.4.11pre3aa1: 00_vm-tweaks-3
Rest of the vm-tweaks not merged because of disagreement. I see
Linus's point but without those swap behaviour sucks. For now
I left them since they're well tested, I will look more into this
shortly.
Only in 2.4.11pre3aa1: 10_compiler.h-1
Move #include <linux/compiler.h> into include/linux/kernel.h to avoid
all the present/future compilation troubles. Assume likely/unlikely
are always available in all kernel code.
Only in 2.4.10aa1: 10_highmem-debug-3
Only in 2.4.11pre3aa1: 10_highmem-debug-4
Rediffed.
Only in 2.4.11pre3aa1: 50_uml-patch-2.4.10-5.bz2
Only in 2.4.10aa1: 50_uml-patch-2.4.9-8-1.bz2
Only in 2.4.10aa1: 51_uml-ac-to-aa-4
Only in 2.4.11pre3aa1: 51_uml-ac-to-aa-5
Only in 2.4.10aa1: 52_uml-page-offset-raw-1
Only in 2.4.10aa1: 55_uml-sys_personality-1
Only in 2.4.10aa1: 56_uml-rb-mmap-1
Only in 2.4.10aa1: 57_ptrace_disable-1
Only in 2.4.10aa1: 58_uml-tlb-1
Picked last update from user-mode-linux.sourceforge.net .
Only in 2.4.11pre3aa1: 60_tux-2.4.10-ac4-A4.bz2
Only in 2.4.10aa1: 60_tux-2.4.9-ac10-K7
Only in 2.4.10aa1: 60_tux-syscall-1
Only in 2.4.11pre3aa1: 60_tux-syscall-2
Only in 2.4.11pre3aa1: 60_tux-timer_t-1
Picked last TUX update from www.redhat.com/~mingo/ .
URL:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.11pre3aa1/
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.11pre3aa1.bz2
diffstat:
CREDITS | 2
Documentation/Configure.help | 242 +++
Documentation/networking/netlogging.txt | 46
MAINTAINERS | 8
Makefile | 9
arch/alpha/config.in | 5
arch/alpha/kernel/alpha_ksyms.c | 4
arch/alpha/kernel/entry.S | 18
arch/alpha/kernel/proto.h | 5
arch/alpha/kernel/traps.c | 17
arch/alpha/mm/fault.c | 10
arch/arm/config.in | 2
arch/arm/mm/fault-common.c | 2
arch/cris/config.in | 2
arch/cris/mm/fault.c | 2
arch/i386/Makefile | 3
arch/i386/config.in | 15
arch/i386/kernel/entry.S | 16
arch/i386/kernel/i386_ksyms.c | 2
arch/i386/kernel/irq.c | 8
arch/i386/kernel/setup.c | 12
arch/i386/kernel/smp.c | 2
arch/i386/lib/usercopy.c | 8
arch/i386/mm/fault.c | 22
arch/i386/vmlinux.lds.S | 83 +
arch/ia64/config.in | 2
arch/ia64/mm/fault.c | 10
arch/m68k/config.in | 2
arch/m68k/mm/fault.c | 2
arch/mips/config.in | 2
arch/mips/mm/fault.c | 2
arch/mips64/config.in | 3
arch/mips64/mm/fault.c | 2
arch/parisc/config.in | 2
arch/ppc/config.in | 2
arch/ppc/mm/fault.c | 15
arch/s390/config.in | 2
arch/s390/mm/fault.c | 2
arch/s390x/config.in | 2
arch/s390x/mm/fault.c | 2
arch/sh/config.in | 2
arch/sh/mm/fault.c | 4
arch/sparc/config.in | 2
arch/sparc/mm/fault.c | 4
arch/sparc64/config.in | 2
arch/sparc64/mm/fault.c | 2
arch/um/Makefile | 103 +
arch/um/Makefile-i386 | 8
arch/um/Makefile-ia64 | 1
arch/um/Makefile-ppc | 5
arch/um/boot/Makefile | 3
arch/um/config.in | 103 +
arch/um/config.release | 288 ++++
arch/um/defconfig | 293 ++++
arch/um/drivers/Makefile | 50
arch/um/drivers/chan_kern.c | 270 +++
arch/um/drivers/chan_user.c | 250 +++
arch/um/drivers/daemon.h | 39
arch/um/drivers/daemon_kern.c | 128 +
arch/um/drivers/daemon_kern.h | 8
arch/um/drivers/daemon_user.c | 210 +++
arch/um/drivers/etap.h | 34
arch/um/drivers/etap_kern.h | 24
arch/um/drivers/ethertap_kern.c | 139 ++
arch/um/drivers/ethertap_user.c | 231 +++
arch/um/drivers/mcast.h | 36
arch/um/drivers/mcast_kern.c | 168 ++
arch/um/drivers/mcast_kern.h | 8
arch/um/drivers/mcast_user.c | 214 +++
arch/um/drivers/mconsole_kern.c | 235 +++
arch/um/drivers/mconsole_user.c | 168 ++
arch/um/drivers/mmapper_kern.c | 146 ++
arch/um/drivers/net_kern.c | 631 +++++++++
arch/um/drivers/net_kern.h | 66
arch/um/drivers/net_user.c | 65
arch/um/drivers/net_user.h | 43
arch/um/drivers/slip.h | 33
arch/um/drivers/slip_kern.c | 106 +
arch/um/drivers/slip_kern.h | 8
arch/um/drivers/slip_user.c | 284 ++++
arch/um/drivers/ssl.c | 310 ++++
arch/um/drivers/ssl.h | 23
arch/um/drivers/stdio_console.c | 294 ++++
arch/um/drivers/stdio_console.h | 26
arch/um/drivers/stdio_console_user.c | 53
arch/um/drivers/tuntap.h | 38
arch/um/drivers/tuntap_kern.c | 130 +
arch/um/drivers/tuntap_kern.h | 24
arch/um/drivers/tuntap_user.c | 264 +++
arch/um/drivers/ubd.c | 799 +++++++++++
arch/um/drivers/ubd_user.c | 474 +++++++
arch/um/fs/Makefile | 16
arch/um/fs/hostfs/Makefile | 31
arch/um/fs/hostfs/hostfs.h | 74 +
arch/um/fs/hostfs/hostfs_kern.c | 782 +++++++++++
arch/um/fs/hostfs/hostfs_user.c | 337 ++++
arch/um/include/chan.h | 129 +
arch/um/include/debug.h | 9
arch/um/include/kern.h | 42
arch/um/include/kern_util.h | 130 +
arch/um/include/mconsole.h | 49
arch/um/include/mconsole_kern.h | 47
arch/um/include/mem_user.h | 60
arch/um/include/process.h | 26
arch/um/include/signal_kern.h | 27
arch/um/include/signal_user.h | 29
arch/um/include/sysdep-i386/ptrace.h | 63
arch/um/include/sysdep-i386/sigcontext.h | 26
arch/um/include/sysdep-i386/syscalls.h | 55
arch/um/include/sysdep-ia64/ptrace.h | 26
arch/um/include/sysdep-ia64/sigcontext.h | 20
arch/um/include/sysdep-ia64/syscalls.h | 20
arch/um/include/sysdep-ppc/ptrace.h | 96 +
arch/um/include/sysdep-ppc/sigcontext.h | 67
arch/um/include/sysdep-ppc/syscalls.h | 50
arch/um/include/sysrq.h | 6
arch/um/include/ubd_user.h | 72 +
arch/um/include/umid.h | 18
arch/um/include/umn.h | 27
arch/um/include/user.h | 27
arch/um/include/user_util.h | 139 ++
arch/um/kernel/Makefile | 78 +
arch/um/kernel/current.c | 24
arch/um/kernel/exec_kern.c | 125 +
arch/um/kernel/exec_user.c | 46
arch/um/kernel/init_task.c | 56
arch/um/kernel/irq.c | 812 ++++++++++++
arch/um/kernel/irq_user.c | 165 ++
arch/um/kernel/ksyms.c | 23
arch/um/kernel/mem.c | 206 +++
arch/um/kernel/mem_user.c | 215 +++
arch/um/kernel/mprot.h | 6
arch/um/kernel/process.c | 251 +++
arch/um/kernel/process_kern.c | 785 +++++++++++
arch/um/kernel/ptrace.c | 247 +++
arch/um/kernel/reboot.c | 54
arch/um/kernel/resource.c | 23
arch/um/kernel/setup.c | 19
arch/um/kernel/signal_kern.c | 393 +++++
arch/um/kernel/signal_user.c | 226 +++
arch/um/kernel/smp.c | 141 ++
arch/um/kernel/sys_call_table.c | 437 ++++++
arch/um/kernel/syscall_kern.c | 351 +++++
arch/um/kernel/syscall_user.c | 175 ++
arch/um/kernel/sysrq.c | 72 +
arch/um/kernel/time.c | 120 +
arch/um/kernel/time_kern.c | 131 +
arch/um/kernel/tlb.c | 194 ++
arch/um/kernel/trap_kern.c | 356 +++++
arch/um/kernel/trap_user.c | 398 +++++
arch/um/kernel/uaccess_user.c | 125 +
arch/um/kernel/um_arch.c | 375 +++++
arch/um/kernel/umid.c | 214 +++
arch/um/kernel/unmap.c | 34
arch/um/kernel/user_syms.c | 112 +
arch/um/kernel/user_util.c | 337 ++++
arch/um/link.ld.in | 105 +
arch/um/main.c | 204 +++
arch/um/ptproxy/Makefile | 28
arch/um/ptproxy/proxy.c | 285 ++++
arch/um/ptproxy/ptproxy.h | 42
arch/um/ptproxy/ptrace.c | 209 +++
arch/um/ptproxy/sysdep.c | 59
arch/um/ptproxy/sysdep.h | 13
arch/um/ptproxy/wait.c | 79 +
arch/um/ptproxy/wait.h | 18
arch/um/sys-i386/Makefile | 49
arch/um/sys-i386/ksyms.c | 16
arch/um/sys-i386/ldt.c | 22
arch/um/sys-i386/ptrace.c | 76 +
arch/um/sys-i386/ptrace_user.c | 25
arch/um/sys-i386/sigcontext.c | 46
arch/um/sys-i386/syscalls.c | 68 +
arch/um/sys-i386/sysrq.c | 22
arch/um/sys-ia64/Makefile | 26
arch/um/sys-ppc/Makefile | 78 +
arch/um/sys-ppc/misc.S | 116 +
arch/um/sys-ppc/miscthings.c | 56
arch/um/sys-ppc/ptrace.c | 28
arch/um/sys-ppc/ptrace_user.c | 39
arch/um/sys-ppc/sigcontext.c | 43
arch/um/tlb.h | 1
drivers/block/loop.c | 4
drivers/char/Makefile | 6
drivers/md/Makefile | 2
drivers/md/lvm-fs.c | 619 +++++++++
drivers/md/lvm-internal.h | 105 +
drivers/md/lvm-snap.c | 451 ++++--
drivers/md/lvm-snap.h | 47
drivers/md/lvm.c | 2097 +++++++++++++------------------
drivers/net/Config.in | 2
drivers/net/Makefile | 2
drivers/net/eepro100.c | 21
drivers/net/netconsole.c | 331 ++++
drivers/net/tulip/tulip_core.c | 22
fs/binfmt_elf.c | 47
fs/block_dev.c | 6
fs/buffer.c | 56
fs/dcache.c | 25
fs/exec.c | 4
fs/ext2/inode.c | 5
fs/inode.c | 6
fs/namei.c | 14
fs/proc/proc_misc.c | 62
fs/select.c | 2
include/asm-alpha/fcntl.h | 1
include/asm-alpha/mmzone.h | 2
include/asm-alpha/module.h | 4
include/asm-alpha/rwsem.h | 208 ---
include/asm-alpha/timex.h | 4
include/asm-alpha/uaccess.h | 40
include/asm-alpha/unistd.h | 4
include/asm-arm/timex.h | 4
include/asm-cris/timex.h | 4
include/asm-i386/fcntl.h | 1
include/asm-i386/hw_irq.h | 13
include/asm-i386/module.h | 4
include/asm-i386/page.h | 4
include/asm-i386/page_offset.h | 6
include/asm-i386/pgtable.h | 4
include/asm-i386/processor.h | 4
include/asm-i386/rwsem.h | 226 ---
include/asm-i386/smplock.h | 3
include/asm-i386/timex.h | 4
include/asm-i386/uaccess.h | 5
include/asm-ia64/fcntl.h | 1
include/asm-ia64/timex.h | 4
include/asm-m68k/timex.h | 4
include/asm-mips/timex.h | 5
include/asm-mips64/timex.h | 4
include/asm-parisc/timex.h | 4
include/asm-ppc/fcntl.h | 1
include/asm-ppc/timex.h | 4
include/asm-s390/timex.h | 4
include/asm-s390x/timex.h | 4
include/asm-sh/timex.h | 4
include/asm-sparc/fcntl.h | 1
include/asm-sparc/timex.h | 4
include/asm-sparc64/fcntl.h | 1
include/asm-sparc64/timex.h | 4
include/asm-um/a.out.h | 18
include/asm-um/archparam-i386.h | 26
include/asm-um/archparam-ppc.h | 41
include/asm-um/atomic.h | 6
include/asm-um/bitops.h | 6
include/asm-um/boot.h | 6
include/asm-um/bugs.h | 6
include/asm-um/byteorder.h | 6
include/asm-um/cache.h | 6
include/asm-um/checksum.h | 6
include/asm-um/cobalt.h | 6
include/asm-um/current.h | 26
include/asm-um/delay.h | 7
include/asm-um/desc.h | 6
include/asm-um/div64.h | 6
include/asm-um/dma.h | 10
include/asm-um/elf.h | 16
include/asm-um/errno.h | 6
include/asm-um/fcntl.h | 6
include/asm-um/fixmap.h | 6
include/asm-um/floppy.h | 6
include/asm-um/hardirq.h | 6
include/asm-um/hdreg.h | 6
include/asm-um/highmem.h | 6
include/asm-um/hw_irq.h | 10
include/asm-um/ide.h | 6
include/asm-um/init.h | 11
include/asm-um/io.h | 6
include/asm-um/ioctl.h | 6
include/asm-um/ioctls.h | 6
include/asm-um/ipc.h | 6
include/asm-um/ipcbuf.h | 6
include/asm-um/irq.h | 27
include/asm-um/keyboard.h | 6
include/asm-um/linux_logo.h | 6
include/asm-um/locks.h | 6
include/asm-um/mca_dma.h | 6
include/asm-um/mman.h | 6
include/asm-um/mmu.h | 6
include/asm-um/mmu_context.h | 25
include/asm-um/module.h | 6
include/asm-um/msgbuf.h | 6
include/asm-um/mtrr.h | 6
include/asm-um/namei.h | 6
include/asm-um/page.h | 40
include/asm-um/page_offset.h | 1
include/asm-um/param.h | 24
include/asm-um/pci.h | 6
include/asm-um/pgalloc.h | 144 ++
include/asm-um/pgtable.h | 378 +++++
include/asm-um/poll.h | 6
include/asm-um/posix_types.h | 6
include/asm-um/processor-generic.h | 190 ++
include/asm-um/processor-i386.h | 6
include/asm-um/processor-ppc.h | 15
include/asm-um/ptrace.h | 32
include/asm-um/resource.h | 6
include/asm-um/rwlock.h | 6
include/asm-um/rwsem-spin.h | 6
include/asm-um/rwsem_xchgadd.h | 6
include/asm-um/scatterlist.h | 6
include/asm-um/segment.h | 4
include/asm-um/semaphore.h | 6
include/asm-um/sembuf.h | 6
include/asm-um/serial.h | 6
include/asm-um/shmbuf.h | 6
include/asm-um/shmparam.h | 6
include/asm-um/sigcontext-generic.h | 6
include/asm-um/sigcontext-i386.h | 6
include/asm-um/sigcontext-ppc.h | 10
include/asm-um/siginfo.h | 6
include/asm-um/signal.h | 14
include/asm-um/smp.h | 18
include/asm-um/smplock.h | 6
include/asm-um/socket.h | 6
include/asm-um/sockios.h | 6
include/asm-um/softirq.h | 13
include/asm-um/spinlock.h | 10
include/asm-um/stat.h | 6
include/asm-um/statfs.h | 6
include/asm-um/string.h | 7
include/asm-um/system-generic.h | 49
include/asm-um/system-i386.h | 6
include/asm-um/system-ppc.h | 16
include/asm-um/termbits.h | 6
include/asm-um/termios.h | 6
include/asm-um/timex.h | 19
include/asm-um/tlb.h | 1
include/asm-um/types.h | 6
include/asm-um/uaccess.h | 184 ++
include/asm-um/unaligned.h | 6
include/asm-um/unistd.h | 100 +
include/asm-um/user.h | 6
include/asm-um/vga.h | 6
include/linux/blk.h | 9
include/linux/condsched.h | 14
include/linux/dcache.h | 2
include/linux/errno.h | 3
include/linux/fs.h | 20
include/linux/hostfs_fs_i.h | 21
include/linux/kernel.h | 3
include/linux/kernel_stat.h | 49
include/linux/lvm.h | 331 +---
include/linux/mm.h | 51
include/linux/netdevice.h | 2
include/linux/numa_sched.h | 53
include/linux/rwsem-spinlock.h | 62
include/linux/rwsem.h | 168 +-
include/linux/sched.h | 102 -
include/linux/slab.h | 2
include/linux/socket.h | 5
include/linux/spinlock.h | 16
include/linux/swap.h | 8
include/linux/sysctl.h | 55
include/linux/time.h | 42
include/linux/timer.h | 2
include/linux/tty.h | 3
include/net/sock.h | 4
include/net/tcp.h | 13
include/net/tux.h | 753 +++++++++++
include/net/tux_u.h | 164 ++
init/main.c | 1
kernel/exit.c | 16
kernel/fork.c | 24
kernel/ksyms.c | 20
kernel/printk.c | 2
kernel/sched.c | 161 +-
kernel/sysctl.c | 2
kernel/time.c | 11
kernel/timer.c | 14
lib/Makefile | 7
lib/rwsem-spinlock.c | 239 ---
lib/rwsem.c | 233 ---
lib/vsprintf.c | 7
mm/filemap.c | 170 ++
mm/highmem.c | 3
mm/memory.c | 22
mm/mmap.c | 17
mm/page_alloc.c | 91 +
mm/slab.c | 3
mm/swap.c | 2
mm/swapfile.c | 1
mm/vmalloc.c | 4
mm/vmscan.c | 23
net/Config.in | 1
net/Makefile | 1
net/ipv4/tcp.c | 2
net/ipv4/tcp_minisocks.c | 2
net/netsyms.c | 19
net/socket.c | 120 +
net/tux/Config.in | 7
net/tux/Makefile | 16
net/tux/abuf.c | 177 ++
net/tux/accept.c | 842 ++++++++++++
net/tux/cachemiss.c | 258 +++
net/tux/cgi.c | 211 +++
net/tux/extcgi.c | 325 ++++
net/tux/input.c | 783 +++++++++++
net/tux/logger.c | 785 +++++++++++
net/tux/main.c | 1252 ++++++++++++++++++
net/tux/mod.c | 243 +++
net/tux/output.c | 267 +++
net/tux/parser.h | 92 +
net/tux/postpone.c | 77 +
net/tux/proc.c | 806 +++++++++++
net/tux/proto_ftp.c | 1662 ++++++++++++++++++++++++
net/tux/proto_http.c | 1320 +++++++++++++++++++
net/tux/redirect.c | 153 ++
net/tux/times.c | 176 ++
net/tux/times.h | 26
net/tux/userspace.c | 27
411 files changed, 35205 insertions(+), 2888 deletions(-)
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!news1.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: Fri, 5 Oct 2001 23:27:35 +0530
From: Dipankar Sarma <dipan...@in.ibm.com>
To: and...@suse.de
Cc: linux-ker...@vger.kernel.org
Subject: Re: 2.4.11pre3aa1
Original-Message-ID: <20011005232735.A23554@in.ibm.com>
Reply-To: dipan...@in.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Fri, 5 Oct 2001 17:53:20 GMT
Message-ID: <fa.c27bkev.11j0j3r@ifi.uio.no>
Lines: 22
In article <20011004225708.A...@athlon.random> Andrea Arcangeli wrote:
> FYI: the next things I will try to concentrate on the next days are:
> 4) rcu, Dipankar, could you send me your latest version, the design that we
> agreed that only adds a per-cpu sequence number inc (not a branch)
> in schedule?
The latest patch based on our agreed design (2.4.10) is available at -
http://lse.sourceforge.net/locking/patches/rcu-2.4.10-1.patch
I will make a 2.4.11preX patch as soon as I can get to that.
Thanks
Dipankar
--
Dipankar Sarma <dipan...@in.ibm.com> Project: http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
-
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!news1.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: Sun, 7 Oct 2001 01:35:58 +0200
From: Andrea Arcangeli <and...@suse.de>
To: linux-ker...@vger.kernel.org
Subject: Re: 2.4.11pre3aa1
Original-Message-ID: <20011007013558.M724@athlon.random>
Original-References: <20011004225708.A...@athlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011004225708.A724@athlon.random>;
from andrea@suse.de on Thu, Oct 04, 2001 at 10:57:09PM +0200
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: Sat, 6 Oct 2001 23:38:22 GMT
Message-ID: <fa.gacangv.1gggh2e@ifi.uio.no>
References: <fa.g8sco0v.1j0mgi3@ifi.uio.no>
Lines: 11
On Thu, Oct 04, 2001 at 10:57:09PM +0200, Andrea Arcangeli wrote:
> 2) Hugh's locking cleanups
checked now (of course it's just in pre4), very nice.
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/