* 2.1.88, adds a bunch of new functionality to
  the swapper.  The main changes are:

* All swapping goes through the swap cache (aka. page cache) now.

* There is no longer a swap lock map.  Because we need to atomically
  test and create a new swap-cache page in order to do swap IO, it is
  sufficient just to lock the struct page itself.  Having only one
  layer of locking to deal with removes a number of races concerning
  swapping shared pages.

* We can swap shared pages, and still keep them shared when they are
  swapped back in!!!  Currently, only private shared pages (as in pages
  shared after a fork()) benefit from this, but the basic mechanism will
  be appropriate for MAP_ANONYMOUS | MAP_SHARED pages too
  (implementation to follow).  Pages will remain shared after a swapoff.

* The page cache is now quite happy dealing with swap-cache pages too.
  In particular, write-ahead and read-ahead of swap through the page
  cache will work fine (and in fact, write-ahead does get done already
  under certain circumstances with this patch --- that's essentially how
  the swapping of shared pages gets done).  Support code to perform
  asynchronous readahead of swap is included, but is not actually used
  anywhere yet.

  I've tested with a number of forked processes running with a shared
  working set larger than physical memory, and with SysV shared memory.
  I haven't found any problems with it so far.

Linus: I've also changed the way we consider us to need more memory in kswapd,
       but that was entirely orthogonal and did not impact these patches. ]

[Changelog pieced together by davej]

Ok, 2.1.87 is out there on ftp.kernel.org now, and it has the clever
PROT_NONE thing done. It seems to work for the little test-case I wrote,
and I also verified that swapping still works, so it seems to be all ok.
I'd still like people who have test programs or similar to actually check
it out,

                Linus

- Update makefile version (forgot to in .83)
- fixes a (very obscure, possibly never happens) autofs bug.
- fix missing ; compile error in mm/filemap.c
- MS_NODIRATIME support.

[changelog summary by davej]

I just made a pre-2.1.81 available on ftp.kernel.org.
This fixes the known problems of 2.1.80, and also makes the interrupt
routing by default look like it always used to look - everything goes
through the traditional external 8259A-compatible logic.
The code to handle IO-APIC interrupt routing is still there, but as no
interrupts are actually marked as io-apic interrupts you don't see it in
action yet. The advantage of this is that people who want to work on this
have a base that contains all the logic, and that we only need to figure
out how to reliably make all the IRQ routing decisions.

                Linus

This release should fix a few networking problems, and the NFS client is
hopefully fairly stable even under the kinds of loads we have here at
Transmeta.

The 2.1.80 release also contains some initial ARM support, and contains
Ingo Molnar's better SMP interrupt handling.

NOTE NOTE NOTE! The new SMP interrupt handling is currently not very good
at autodetection. This can be a real problem, and _before_ booting the
2.1.80 kernel as compiled for SMP you should probably try to figure out a
possible IRQ override line by doing:

        echo -n pirq=; echo `scanpci -f | grep T_L | cut -c56-` | sed 's/ /,/g'
which for me gives
        pirq=0x00,0x09,0x0b

Then, after doing the above, boot into 2.1.80 and see if it finds your PCI
interrupt lines correctly. If it does, everything is fine. If it doesn't,
you need to boot with the pirq setting that you determined earlier, by
giving the kernel the pirq data at the bootup command line or by using the
LILO "append=" feature (or similar features in other bootloaders).
We'll certainly have to make the autodetection work reliably, but in the
meantime the command-line approach at least gives us a way to test the
more fundamental impacts of better interrupt handling.

                Linus

 I just put a pre-2.1.80 on ftp.kernel.org that should fix the fat-related
problems. The reason I put it there is because I got several patches that
fixed the FAT problems _and_ something else, and they all obviously
clashed with each other so neither part got applied.

 So I'd ask people who sent me patches to maybe re-send the parts of the
patches that are still relevant,

                Linus