2.4.1-test10

2.4.1-test10

[Linus Torvalds]

The ChangeLog may not be 100% complete. The physically big things are the
PPC and ACPI updates, even if most people won't notice.

		Linus

----

pre10:
 - got a few too-new R128 #defines in the Radeon merge. Fix.
 - tulip driver update from Jeff Garzik
 - more cpq and DAC elevator fixes from Jens. Looks good.
 - Petr Vandrovec: nicer ncpfs behaviour
 - Andy Grover: APCI update
 - Cort Dougan: PPC update
 - David Miller: sparc updates
 - David Miller: networking updates
 - Neil Brown: RAID5 fixes

pre9:
 - cpq array driver elevator fixes 
 - merge radeon driver from X CVS tree
 - ispnp cleanups
 - emu10k unlock on error fixes
 - hpfs doesn't allow truncate to larger

pre8:
 - Don't drop a megabyte off the old-style memory size detection
 - remember to UnlockPage() in ramfs_writepage()
 - 3c59x driver update from Andrew Morton
 - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton
 - dmfe.c module init fix: Andrew Morton
 - dynamic XMM support. Andrea Arkangeli.
 - ReiserFS merge
 - USB hotplug updates/fixes
 - boots on real i386 machines
 - blk-14 from Jens Axboe
 - fix DRM R128/AGP dependency
 - fix n_tty "canon" mode SMP race
 - ISDN fixes
 - ppp UP deadlock attack fix
 - FAT fat_cache SMP race fix
 - VM balancing tuning
 - Locked SHM segment deadlock fix
 - fork() page table copy race fix

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[David Ford]

Linus Torvalds wrote:

> The ChangeLog may not be 100% complete. The physically big things are the
> PPC and ACPI updates, even if most people won't notice.
>
>                 Linus
>
> ----
>
> pre10:
>  - got a few too-new R128 #defines in the Radeon merge. Fix.
>  - tulip driver update from Jeff Garzik
>  - more cpq and DAC elevator fixes from Jens. Looks good.
>  - Petr Vandrovec: nicer ncpfs behaviour
>  - Andy Grover: APCI update
>  - Cort Dougan: PPC update
>  - David Miller: sparc updates
>  - David Miller: networking updates
>  - Neil Brown: RAID5 fixes

Do the tulip driver updates address the increasingly common NETDEV timeout
repots?

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Marcelo Tosatti]

Any technical reason why the background page aging fix was not applied?

On Mon, 22 Jan 2001, Linus Torvalds wrote:

> The ChangeLog may not be 100% complete. The physically big things are the
> PPC and ACPI updates, even if most people won't notice.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Derek Wildstar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am having ACPI problems with a dell inspiron 5000e, I hear it has a
broken implementation of APM, so could quite possibly have a broken ACPI
also.  When ACPI is enabled in the kernel (-pre10 and earlier ones also)
the system soft-hangs after loading the ACPI definitions.  both
ctrl-alt-del and alt-sysrq-b will restart the system.  If there is
anything else i can do to provide more info please let me know.  Running
without ACPI or APM is stable, even with the r128 kernel
drivers/XF4.0.2...battery usage is a bit quick, however =)

- -dwild


Linus Torvalds wrote:

> The ChangeLog may not be 100% complete. The physically big things are the
> PPC and ACPI updates, even if most people won't notice.
>
>                 Linus
>
> ----
>
> pre10:
>  - got a few too-new R128 #defines in the Radeon merge. Fix.
>  - tulip driver update from Jeff Garzik
>  - more cpq and DAC elevator fixes from Jens. Looks good.
>  - Petr Vandrovec: nicer ncpfs behaviour
>  - Andy Grover: APCI update
>  - Cort Dougan: PPC update
>  - David Miller: sparc updates
>  - David Miller: networking updates
>  - Neil Brown: RAID5 fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6bRDYmFSlcxy4R48RAjx8AJ9EgM9A8k5sUQWu91w/lt2hZcfW5wCdFYi8
S+lZ54tOtr9BMUSn503hj68=
=d48f
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Jeff Garzik]

David Ford wrote:
> 
> Linus Torvalds wrote:
> 
> > The ChangeLog may not be 100% complete. The physically big things are the
> > PPC and ACPI updates, even if most people won't notice.
> >
> >                 Linus
> >
> > ----
> >
> > pre10:
> >  - got a few too-new R128 #defines in the Radeon merge. Fix.
> >  - tulip driver update from Jeff Garzik
> >  - more cpq and DAC elevator fixes from Jens. Looks good.
> >  - Petr Vandrovec: nicer ncpfs behaviour
> >  - Andy Grover: APCI update
> >  - Cort Dougan: PPC update
> >  - David Miller: sparc updates
> >  - David Miller: networking updates
> >  - Neil Brown: RAID5 fixes
> 
> Do the tulip driver updates address the increasingly common NETDEV timeout
> repots?

In general you can answer this yourself by reading
drivers/net/tulip/ChangeLog.

I don't see increasingly common timeout reports.. with which hardware? 
They are likely on the newer LinkSys 4.1 cards, and there are still
problesm with PNIC.  Outside of that, other cards should be ok.

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Ben Ford]

Jeff Garzik wrote:

> David Ford wrote:
> >
> > Linus Torvalds wrote:
> >
> > > The ChangeLog may not be 100% complete. The physically big things are the
> > > PPC and ACPI updates, even if most people won't notice.
> > >
> > >                 Linus
> > >
> > > ----
> > >
> > > pre10:
> > >  - got a few too-new R128 #defines in the Radeon merge. Fix.
> > >  - tulip driver update from Jeff Garzik
> > >  - more cpq and DAC elevator fixes from Jens. Looks good.
> > >  - Petr Vandrovec: nicer ncpfs behaviour
> > >  - Andy Grover: APCI update
> > >  - Cort Dougan: PPC update
> > >  - David Miller: sparc updates
> > >  - David Miller: networking updates
> > >  - Neil Brown: RAID5 fixes
> >
> > Do the tulip driver updates address the increasingly common NETDEV timeout
> > repots?
>
> In general you can answer this yourself by reading
> drivers/net/tulip/ChangeLog.
>
> I don't see increasingly common timeout reports.. with which hardware?
> They are likely on the newer LinkSys 4.1 cards, and there are still
> problesm with PNIC.  Outside of that, other cards should be ok.
>

I have this problem also.

I have several machines that are almost unuseable due to the network device.  I
need to do an ifconfig down/up to get connectivity back again.  That doesn't
work so handy for a headless router . . . .

My desktop machine (2.3.9x - present) has dropped the network 4 or 5 times a day
for months.

-b


>
>         Jeff
>
> --
> Jeff Garzik       | "You see, in this world there's two kinds of
> Building 1024     |  people, my friend: Those with loaded guns
> MandrakeSoft      |  and those who dig. You dig."  --Blondie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[David Ford]

> > Do the tulip driver updates address the increasingly common NETDEV timeout
> > repots?
>
> In general you can answer this yourself by reading
> drivers/net/tulip/ChangeLog.
>
> I don't see increasingly common timeout reports.. with which hardware?
> They are likely on the newer LinkSys 4.1 cards, and there are still
> problesm with PNIC.  Outside of that, other cards should be ok.

I have four machines now that exhibit this problem.  Three have in them the
Linksys card family, similar PCI cards, one is my laptop which I have three
different cardbus cards but they all use the tulip driver.

In the PCI situation, not all machines using these cards act the same way.
I got a 10 pack of LNE100TX cards and so far only two out of the batch are doing
this, they are all the same revision, identical in every way that I've found.

The three cardbus cards are slightly different in numerous ways.  For them they
normally fault with an APM event, an eject/insert cycle via software will reset
them and a link down/up won't fix it.  For the PCI cards most times a link
down/up cycle will fix them.  It's a 2.4 v.s. 2.2 issue, the 2.2 kernels aren't
exhibiting this error.

The PCI cards are hard to get into this state, sometimes they'll run millions of
packets for months on end before they'll burp.  Sometimes it'll happen three
times a night.  The amount of traffic doesn't seem to matter, nor does the type
of traffic.

00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
        Subsystem: Netgear FA310TX
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 set
        Interrupt: pin A routed to IRQ 9
        Region 0: I/O ports at 6400 [size=256]
        Region 1: Memory at e4000000 (32-bit, non-prefetchable) [size=256]
        Expansion ROM at <unassigned> [disabled] [size=256K]


I say increasingly common because the more machines I bring on with 2.4 v.s. 2.3
or testNN kernels, the more the systems burp on this.  I.e. a kernel from 6
months ago takes 2-3 months to burp.  Last week's kernel burps once a week.

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[Matti Aarnio]

On Tue, Jan 23, 2001 at 10:48:16AM +0000, David Ford wrote:
> The three cardbus cards are slightly different in numerous ways.  For
> them they normally fault with an APM event, an eject/insert cycle via
> software will reset hem and a link down/up won't fix it.  For the PCI
> cards most times a link down/up cycle will fix them.  It's a 2.4 v.s. 2.2
> issue, the 2.2 kernels aren't exhibiting this error.

	I see that with my AT2800TX cardbus card as well.
	(Using Tulip driver, no less.)

> The PCI cards are hard to get into this state, sometimes they'll run
> millions of packets for months on end before they'll burp.  Sometimes
> it'll happen three times a night.  The amount of traffic doesn't seem
> to matter, nor does the type of traffic.

	Sounds like timing issue.

> -d

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[David Ford]

Matti Aarnio wrote:

> On Tue, Jan 23, 2001 at 10:48:16AM +0000, David Ford wrote:
> > The three cardbus cards are slightly different in numerous ways.  For
> > them they normally fault with an APM event, an eject/insert cycle via
> > software will reset hem and a link down/up won't fix it.  For the PCI
> > cards most times a link down/up cycle will fix them.  It's a 2.4 v.s. 2.2
> > issue, the 2.2 kernels aren't exhibiting this error.
>
>         I see that with my AT2800TX cardbus card as well.
>         (Using Tulip driver, no less.)
>
> > The PCI cards are hard to get into this state, sometimes they'll run
> > millions of packets for months on end before they'll burp.  Sometimes
> > it'll happen three times a night.  The amount of traffic doesn't seem
> > to matter, nor does the type of traffic.
>
>         Sounds like timing issue.

Hmm, should we class these as two similar but different bugs?  I suspect they
are both timing but there is another stimulus operating differently.

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[Matti Aarnio]

On Tue, Jan 23, 2001 at 11:13:48AM +0000, David Ford wrote:
> > > The three cardbus cards are slightly different in numerous ways.  For
> > > them they normally fault with an APM event, an eject/insert cycle via
> > > software will reset hem and a link down/up won't fix it.  For the PCI
....
> > > The PCI cards are hard to get into this state, sometimes they'll run
> > > millions of packets for months on end before they'll burp.  Sometimes
> > > it'll happen three times a night.  The amount of traffic doesn't seem
> > > to matter, nor does the type of traffic.
> >
> >         Sounds like timing issue.
> 
> Hmm, should we class these as two similar but different bugs?  I suspect they
> are both timing but there is another stimulus operating differently.

  I think they are separate problems.
  The first is power-management suspend/resume issue, and possibly
  PCMCIA problem at software re-insert of card (which never was taken
  out *physically*).

  If I pull the cardbus card out, make sure the  "dhcpcd eth0" has
  died (e.g. I kill it), and re-insert the card, system is highly
  likely to work.

  It is just that if I suspend my laptop with card in, and wakeup it
  latter, there I encounter dead network card.


  Hangup/barfing on system which never suspends will never excercise
  suspend/resume codepaths, but may poke at wrong moment at some register,
  which causes card severe indigestion problems - rx/tx hangup.

  Sadly a "100% Compatible" usually means: "beware odd problems"

> -d

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[David Ford]

Matti Aarnio wrote:

>   I think they are separate problems.
>   The first is power-management suspend/resume issue, and possibly
>   PCMCIA problem at software re-insert of card (which never was taken
>   out *physically*).
>
>   If I pull the cardbus card out, make sure the  "dhcpcd eth0" has
>   died (e.g. I kill it), and re-insert the card, system is highly
>   likely to work.

In my cardbus instance, a simple cardctl eject/insert is sufficient, I don't need
to manually cycle it.

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

RE: 2.4.1-test10

[Jonathan Earle]

> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com]

> > Do the tulip driver updates address the increasingly common 
> NETDEV timeout
> > repots?
> 
> I don't see increasingly common timeout reports.. with which 
> hardware? 
> They are likely on the newer LinkSys 4.1 cards, and there are still
> problesm with PNIC.  Outside of that, other cards should be ok.

Hi Jeff,

Have you looked at the packet loss issue on the Znyx 4port cards?  Even
using the latest tulip driver, packet loss is still apparent with moderate
loads.

Cheers!
Jon

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Jeff Garzik]

Jonathan Earle wrote:
> Have you looked at the packet loss issue on the Znyx 4port cards?  Even
> using the latest tulip driver, packet loss is still apparent with moderate
> loads.

I replied privately; but I just wanted to add that bug reports for the
in-kernel Tulip driver should be sent to the bug tracking system at
http://sourceforge.net/projects/tulip/

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Marcelo Tosatti]

On Tue, 23 Jan 2001, Andre Hedrick wrote:

> Just my nickel on the issue.

Andre, 

This patch I'm talking about is for a different issue from what was
discussed in the IO clustering thread.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[Jeff Garzik]

David Ford wrote:
> 
> > > Do the tulip driver updates address the increasingly common NETDEV timeout
> > > repots?
> >
> > In general you can answer this yourself by reading
> > drivers/net/tulip/ChangeLog.
> >
> > I don't see increasingly common timeout reports.. with which hardware?
> > They are likely on the newer LinkSys 4.1 cards, and there are still
> > problesm with PNIC.  Outside of that, other cards should be ok.
> 
> I have four machines now that exhibit this problem.  Three have in them the
> Linksys card family, similar PCI cards, one is my laptop which I have three
> different cardbus cards but they all use the tulip driver.
> 
> In the PCI situation, not all machines using these cards act the same way.
> I got a 10 pack of LNE100TX cards and so far only two out of the batch are doing
> this, they are all the same revision, identical in every way that I've found.
> 
> The three cardbus cards are slightly different in numerous ways.  For them they
> normally fault with an APM event, an eject/insert cycle via software will reset
> them and a link down/up won't fix it.  For the PCI cards most times a link
> down/up cycle will fix them.  It's a 2.4 v.s. 2.2 issue, the 2.2 kernels aren't
> exhibiting this error.

Sounds like the PCI PM state is getting mangled.  Can you provide a
"lspci -vvv", as root, for each of the three cardbus cards?  Make sure
to run lspci when the cards are up and active and working.


> The PCI cards are hard to get into this state, sometimes they'll run millions of
> packets for months on end before they'll burp.  Sometimes it'll happen three
> times a night.  The amount of traffic doesn't seem to matter, nor does the type
> of traffic.
> 

> 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
>         Subsystem: Netgear FA310TX

If the link is getting lost (which may explain the randomness of the
error), the following patch might help: 
http://sourceforge.net/patch/?func=detailpatch&patch_id=103294&group_id=13004

There are still some media fixes that need to be integrated from the
Becker driver, and tested, too.

Also, downloading tulip-diag.c and capturing the register state before
and after the breakage is useful.  A useful command line is "tulip-diag
-mmmaaavvveef".

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Linus Torvalds]

On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
> 
> Any technical reason why the background page aging fix was not applied?

Because I have not heard anybody claim that it makes a huge difference..

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Andre Hedrick]

On Tue, 23 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
> > 
> > Any technical reason why the background page aging fix was not applied?
> 
> Because I have not heard anybody claim that it makes a huge difference..

Linus,

If it could help speed up the page_list movements because of what appears
to be an offset seek and step direction, thus it is referrence frame for
find these pages is local.  The local reference frame could/should be tied
back to either the head or tail of the page_list for track purposes.

The idea is if we can keep ahead of the laundry list, we may avoid crunch
time in the event that a request of a huge chunk is requested and the busy
beaver has quietly gotten most of the needed pages prepared.  Thus the
possible system-wide delay that can occur may be minimized.

Obviously if you have several big request you get slapped hard.

The point may be that if we have some extra cycles spinning, why not use
them to a painful task when it will not hurt as much?

Just my nickel on the issue.

Cheers,

Andre Hedrick
Linux ATA Development

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Under 2.4.0 I can mount same partition twice.

[Dan Graham]

Hello;
  I don't know if this is a bug or a feature.  While I was
playing around with 2.4.0 I (mistakenly) mounted an ext2
partition twice.  

The excerpt from mount looks like this.
/dev/hda1 on /a1 type ext2 (rw)
/dev/hda1 on /mnt type ext2 (rw)

Under 2.2.13 I get 

mount: /dev/hda1 already mounted or /mnt busy
mount: according to mtab, /dev/hda1 is mounted on /a1

Is this a bug or a feature? 

System is an ABIT VP6, dual PIII 733Mhz, 1gb RAM, 
30g ATA 100 drive, IBM Deskstar.  DMA is on.

Dan 
graham@balance.uoregon.edu


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Under 2.4.0 I can mount same partition twice.

[Andreas Dilger]

Dan Graham writes:
>   I don't know if this is a bug or a feature.  While I was
> playing around with 2.4.0 I (mistakenly) mounted an ext2
> partition twice.  

Feature.

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-test10

[Ed Tomlinson]

On Tue, 23 Jan 2001, Linus Torvalds wrote:

>On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
 
>> Any technical reason why the background page aging fix was not applied?

>Because I have not heard anybody claim that it makes a huge difference..

Linus,

Marcelo's changes make a difference here - enought of a difference that I
spent the time to merge his 'swap_max_pageout' and 'limit_bg_pte_scaning'
patches.

These patches make my system more stable when there is memory preasure.  With 
them I see much less 'jerky' behavior when swapping starts.  Limiting the 
ammout of swapping to what's actually needed seems very effective.  Using pte 
scaning, when under light memory peasure, looks to be effective at keeping 
swapping transparent (and freepages available)...  The effect of limiting the 
bg aging is harder to see but I do notice that going back to a long,  
intermitantly running task, often does not result in a large delay due to 
swapins...

In short think you should take a serious look at Marcelo's latest work.  I 
have included the merged patch.  Marcelo has briefly vetted it but more eyes 
would be a very good idea...

TIA

Ed Tomlinson

BTW - I sent a comment on this thread this morning - it bounced due to a 
knode problem with multiple address.  It said the same things.

---
Only in linux-pre9e/mm/: .depend
diff -u linux/mm/swap.c linux-pre9e/mm/swap.c
--- linux/mm/swap.c	Tue Nov 28 19:52:56 2000
+++ linux-pre9e/mm/swap.c	Thu Jan 18 22:33:42 2001
@@ -200,17 +200,22 @@
 {
 	if (PageInactiveDirty(page)) {
 		del_page_from_inactive_dirty_list(page);
-		add_page_to_active_list(page);
 	} else if (PageInactiveClean(page)) {
 		del_page_from_inactive_clean_list(page);
-		add_page_to_active_list(page);
 	} else {
 		/*
 		 * The page was not on any list, so we take care
 		 * not to do anything.
 		 */
+		goto inc_age;
 	}
 
+	add_page_to_active_list(page);
+	
+	if(bg_page_aging < num_physpages)
+		bg_page_aging++;
+
+inc_age:
 	/* Make sure the page gets a fair chance at staying active. */
 	if (page->age < PAGE_AGE_START)
 		page->age = PAGE_AGE_START;
diff -u linux/mm/vmscan.c linux-pre9e/mm/vmscan.c
--- linux/mm/vmscan.c	Sun Jan 21 21:44:55 2001
+++ linux-pre9e/mm/vmscan.c	Sun Jan 21 11:54:09 2001
@@ -24,32 +24,21 @@
 
 #include <asm/pgalloc.h>
 
-/*
- * The swap-out functions return 1 if they successfully
- * threw something out, and we got a free page. It returns
- * zero if it couldn't do anything, and any other value
- * indicates it decreased rss, but the page was shared.
- *
- * NOTE! If it sleeps, it *must* return 1 to make sure we
- * don't continue with the swap-out. Otherwise we may be
- * using a process that no longer actually exists (it might
- * have died while we slept).
- */
-static void try_to_swap_out(struct mm_struct * mm, struct vm_area_struct* 
vma, unsigned long address, pte_t * page_table, struct page *page)
+int bg_page_aging = 0;
+
+static int try_to_swap_out(struct mm_struct * mm, struct vm_area_struct* 
vma, unsigned long address, pte_t * page_table, struct page *page)
 {
 	pte_t pte;
 	swp_entry_t entry;
 
 	/* Don't look at this pte if it's been accessed recently. */
 	if (ptep_test_and_clear_young(page_table)) {
-		page->age += PAGE_AGE_ADV;
-		if (page->age > PAGE_AGE_MAX)
-			page->age = PAGE_AGE_MAX;
-		return;
+		age_page_up(page);
+		return 0;
 	}
 
 	if (TryLockPage(page))
-		return;
+		return 0;
 
 	/* From this point on, the odds are that we're going to
 	 * nuke this pte, so read and clear the pte.  This hook
@@ -73,11 +62,17 @@
 		set_pte(page_table, swp_entry_to_pte(entry));
 drop_pte:
 		mm->rss--;
-		if (!page->age)
+		if (!page->age) {
 			deactivate_page(page);
+			if(!PageActive(page)) {
+				UnlockPage(page);
+				page_cache_release(page);
+				return 1;
+			}
+		}
 		UnlockPage(page);
 		page_cache_release(page);
-		return;
+		return 0;
 	}
 
 	/*
@@ -121,25 +116,27 @@
 	/* Add it to the swap cache and mark it dirty */
 	add_to_swap_cache(page, entry);
 	set_page_dirty(page);
+	if (bg_page_aging)
+		bg_page_aging--;
 	goto set_swap_pte;
 
 out_unlock_restore:
 	set_pte(page_table, pte);
 	UnlockPage(page);
-	return;
+	return 0;
 }
 
-static int swap_out_pmd(struct mm_struct * mm, struct vm_area_struct * vma, 
pmd_t *dir, unsigned long address, unsigned long end, int count)
+static int swap_out_pmd(struct mm_struct * mm, struct vm_area_struct * vma, 
pmd_t *dir, unsigned long address, unsigned long end, int maxtry, int *count)
 {
 	pte_t * pte;
 	unsigned long pmd_end;
 
 	if (pmd_none(*dir))
-		return count;
+		return maxtry;
 	if (pmd_bad(*dir)) {
 		pmd_ERROR(*dir);
 		pmd_clear(dir);
-		return count;
+		return maxtry;
 	}
 	
 	pte = pte_offset(dir, address);
@@ -153,8 +150,12 @@
 			struct page *page = pte_page(*pte);
 
 			if (VALID_PAGE(page) && !PageReserved(page)) {
-				try_to_swap_out(mm, vma, address, pte, page);
-				if (!--count)
+				*count -= try_to_swap_out(mm, vma, address, pte, page);
+				if (!*count) {
+					maxtry = 0;
+					break;
+				}
+				if (!--maxtry)
 					break;
 			}
 		}
@@ -162,20 +163,20 @@
 		pte++;
 	} while (address && (address < end));
 	mm->swap_address = address + PAGE_SIZE;
-	return count;
+	return maxtry;
 }
 
-static inline int swap_out_pgd(struct mm_struct * mm, struct vm_area_struct 
* vma, pgd_t *dir, unsigned long address, unsigned long end, int count)
+static inline int swap_out_pgd(struct mm_struct * mm, struct vm_area_struct 
* vma, pgd_t *dir, unsigned long address, unsigned long end, int maxtry, int 
*count)
 {
 	pmd_t * pmd;
 	unsigned long pgd_end;
 
 	if (pgd_none(*dir))
-		return count;
+		return maxtry;
 	if (pgd_bad(*dir)) {
 		pgd_ERROR(*dir);
 		pgd_clear(dir);
-		return count;
+		return maxtry;
 	}
 
 	pmd = pmd_offset(dir, address);
@@ -185,23 +186,23 @@
 		end = pgd_end;
 	
 	do {
-		count = swap_out_pmd(mm, vma, pmd, address, end, count);
-		if (!count)
+		maxtry = swap_out_pmd(mm, vma, pmd, address, end, maxtry, count);
+		if (!maxtry)
 			break;
 		address = (address + PMD_SIZE) & PMD_MASK;
 		pmd++;
 	} while (address && (address < end));
-	return count;
+	return maxtry;
 }
 
-static int swap_out_vma(struct mm_struct * mm, struct vm_area_struct * vma, 
unsigned long address, int count)
+static int swap_out_vma(struct mm_struct * mm, struct vm_area_struct * vma, 
unsigned long address, int maxtry, int *count)
 {
 	pgd_t *pgdir;
 	unsigned long end;
 
 	/* Don't swap out areas which are locked down */
 	if (vma->vm_flags & (VM_LOCKED|VM_RESERVED))
-		return count;
+		return maxtry;
 
 	pgdir = pgd_offset(mm, address);
 
@@ -209,16 +210,16 @@
 	if (address >= end)
 		BUG();
 	do {
-		count = swap_out_pgd(mm, vma, pgdir, address, end, count);
-		if (!count)
+		maxtry = swap_out_pgd(mm, vma, pgdir, address, end, maxtry, count);
+		if (!maxtry)
 			break;
 		address = (address + PGDIR_SIZE) & PGDIR_MASK;
 		pgdir++;
 	} while (address && (address < end));
-	return count;
+	return maxtry;
 }
 
-static int swap_out_mm(struct mm_struct * mm, int count)
+static int swap_out_mm(struct mm_struct * mm, int maxtry, int *count)
 {
 	unsigned long address;
 	struct vm_area_struct* vma;
@@ -239,8 +240,8 @@
 			address = vma->vm_start;
 
 		for (;;) {
-			count = swap_out_vma(mm, vma, address, count);
-			if (!count)
+			maxtry = swap_out_vma(mm, vma, address, maxtry, count);
+			if (!maxtry)
 				goto out_unlock;
 			vma = vma->vm_next;
 			if (!vma)
@@ -253,7 +254,7 @@
 
 out_unlock:
 	spin_unlock(&mm->page_table_lock);
-	return !count;
+	return !maxtry;
 }
 
 /*
@@ -269,15 +270,17 @@
 	return nr < SWAP_MIN ? SWAP_MIN : nr;
 }
 
-static int swap_out(unsigned int priority, int gfp_mask)
+static int swap_out(unsigned int priority, int background, int *needed)
 {
-	int counter;
-	int retval = 0;
+	int counter, retval = 0; 
 	struct mm_struct *mm = current->mm;
 
 	/* Always start by trying to penalize the process that is allocating memory 
*/
-	if (mm)
-		retval = swap_out_mm(mm, swap_amount(mm));
+	if (mm) {
+		retval = swap_out_mm(mm, swap_amount(mm),needed);
+                if (!*needed && !background)
+			return 1;
+	}
 
 	/* Then, look at the other mm's */
 	counter = mmlist_nr >> priority;
@@ -299,8 +302,15 @@
 		spin_unlock(&mmlist_lock);
 
 		/* Walk about 6% of the address space each time */
-		retval |= swap_out_mm(mm, swap_amount(mm));
+		retval |= swap_out_mm(mm, swap_amount(mm),needed);
 		mmput(mm);
+		/* 
+		 *  In the case of background aging, stop
+		 *  the scan when we aged the necessary amount
+		 *  of pages.
+		 */
+		if ((background && !bg_page_aging) || (!*needed && !background))
+			break;
 	} while (--counter >= 0);
 	return retval;
 
@@ -626,22 +636,24 @@
 /**
  * refill_inactive_scan - scan the active list and find pages to deactivate
  * @priority: the priority at which to scan
- * @oneshot: exit after deactivating one page
+ * @background: slightly different behaviour for background scanning
  *
  * This function will scan a portion of the active list to find
  * unused pages, those pages will then be moved to the inactive list.
  */
-int refill_inactive_scan(unsigned int priority, int oneshot)
+int refill_inactive_scan(unsigned int priority, int background)
 {
 	struct list_head * page_lru;
 	struct page * page;
-	int maxscan, page_active = 0;
+	int maxscan;
 	int ret = 0;
+	int deactivate = 1;
 
 	/* Take the lock while messing with the list... */
 	spin_lock(&pagemap_lru_lock);
 	maxscan = nr_active_pages >> priority;
 	while (maxscan-- > 0 && (page_lru = active_list.prev) != &active_list) {
+		int page_active = 0;
 		page = list_entry(page_lru, struct page, lru);
 
 		/* Wrong page on list?! (list corruption, should not happen) */
@@ -656,9 +668,19 @@
 		if (PageTestandClearReferenced(page)) {
 			age_page_up_nolock(page);
 			page_active = 1;
-		} else {
+		} else if (deactivate) {
 			age_page_down_ageonly(page);
 			/*
+			 * We're aging down a page. Decrement the counter if it
+ 			 * has not reached zero yet. If it reached zero, and we 			 * are doing 
background scan, stop deactivating pages.
+			 */
+			if (bg_page_aging)
+				bg_page_aging--;
+			else if (background) {
+				deactivate = 0;
+				continue;	
+			}
+			/*
 			 * Since we don't hold a reference on the page
 			 * ourselves, we have to do our test a bit more
 			 * strict then deactivate_page(). This is needed
@@ -672,21 +694,20 @@
 						(page->buffers ? 2 : 1)) {
 				deactivate_page_nolock(page);
 				page_active = 0;
-			} else {
-				page_active = 1;
 			}
 		}
 		/*
 		 * If the page is still on the active list, move it
 		 * to the other end of the list. Otherwise it was
-		 * deactivated by age_page_down and we exit successfully.
+		 * deactivated by deactivate_page_nolock and we exit 
+		 * successfully.
 		 */
 		if (page_active || PageActive(page)) {
 			list_del(page_lru);
 			list_add(page_lru, &active_list);
 		} else {
 			ret = 1;
-			if (oneshot)
+			if (!background)
 				break;
 		}
 	}
@@ -800,13 +821,16 @@
 			schedule();
 		}
 
-		while (refill_inactive_scan(DEF_PRIORITY, 1)) {
+		while (refill_inactive_scan(DEF_PRIORITY, 0)) {
 			if (--count <= 0)
 				goto done;
 		}
 
 		/* If refill_inactive_scan failed, try to page stuff out.. */
-		swap_out(DEF_PRIORITY, gfp_mask);
+		swap_out(DEF_PRIORITY, 0, &count);
+
+		if (count <= 0)
+			goto done; 
 
 		if (--maxtry <= 0)
 				return 0;
@@ -908,6 +932,7 @@
 	 */
 	for (;;) {
 		static int recalc = 0;
+		int count = -1;			/* no limit for bg swapping */
 
 		/* If needed, try to free some memory. */
 		if (inactive_shortage() || free_shortage()) 
@@ -919,7 +944,11 @@
 		 * every minute. This clears old referenced bits
 		 * and moves unused pages to the inactive list.
 		 */
-		refill_inactive_scan(DEF_PRIORITY, 0);
+		refill_inactive_scan(DEF_PRIORITY, 1);
+
+		/* Walk the pte's and age them. */
+		if (bg_page_aging)  
+			swap_out(DEF_PRIORITY, 1, &count);
 
 		/* Once a second, recalculate some VM stats. */
 		if (time_after(jiffies, recalc + HZ)) {
--- linux/include/linux/swap.h	Sun Jan 21 21:44:55 2001
+++ linux-pre9e/include/linux/swap.h	Sun Jan 21 11:59:39 2001
@@ -101,6 +101,7 @@
 extern void swap_setup(void);
 
 /* linux/mm/vmscan.c */
+extern int bg_page_aging;
 extern struct page * reclaim_page(zone_t *);
 extern wait_queue_head_t kswapd_wait;
 extern wait_queue_head_t kreclaimd_wait;
---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/