We need this small change to drivers/scsi/Config.in.  It only affects
people using powermacs since the MESH hardware only exists on
powermacs and clones.

Update my email address and fix an ancient miscalculation. One could argue
that this driver should just be removed. I sent these changes to the
maintainer a few years ago and got no reply.

For 2.5 Gerd Knorr is the video4linux/v4l2 maintainer not me
kraxel@bytesex.org or the list video4linux-list@redhat.com - which is
hosted at but not an RH specific list.

This makes the CONFIG_VIDEO_PROC_FS question depend on CONFIG_PROC_FS.
Additionally, this changes all tests/comments about CONFIG_PROC_FS &&
CONFIG_VIDEO_PROC_FS to be just CONFIG_VIDEO_PROC_FS.

Here are a couple of patches for files in include/asm-i386. Patches
are against 2.5.31.

<linux/config.h> has the normal idempotent construction.

The attached file removes the second #include.

<linux/pagemap.h> has the normal idempotent construction.

The attached file removes the second #include.

[ It's strange how many of us can't spell weird ]

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

Silence hotplug printk()s in input.c
More careful probe and init in atkbd.c and psmouse.c
to avoid triggering bugs in certain keyboards.
Accept old AT (non PS/2) keyboards with limited command set.
Accept Logitech mice which can only do IMPS/2 and not PS2++.
Use a buffer in i8042.c to avoid spinlock deadlocks when
serio_write is called from within serio_interrupt.
Only ask keyboard to resent if the keyboard is there (ie no timeout).
Linus, this should fix both your keyboard and your mouse!

buffers via usb_buffer_alloc in 2.5.x  This helps platforms
where doing a pci_{map,unmap}_single() on every input event
is very inefficient.

Also adds a missing kfree(hid), because the HID struct was never
freed.

Use the new max cache alignment to optimise the layout of struct zone.

struct zone goes from ~270 bytes (UP) to 768 bytes (SMP, x86).  This is
not a trick which should be generally used.

zone->lock and zone->lru_lock are two of the hottest locks in the
kernel.  Their usage patterns are quite independent.  And they have
just been put into the same structure.  It is essential that they not
fall into the same cacheline.

That could be fixed by padding with L1_CACHE_BYTES.  But the problem
with this is that a kernel which was configured for (say) a PIII will
perform poorly on SMP PIV.  This will cause problems for kernel
vendors.  For example, RH currently ship PII and Athlon binaries.  To
get best SMP performance they will end up needing to ship a lot of
differently configured kernels.

To solve this we need to know, at compile time, the maximum L1 size
which this kernel will ever run on.

This patch adds L1_CACHE_SHIFT_MAX to every architecture's cache.h.

Of course it'll break when newer chips come out with increased
cacheline sizes.   Better suggestions are welcome.

Now the LRUs are per-zone, make their lock per-zone as well.

In this patch the per-zone lock shares a cacheline with the zone's
buddy list lock, which is very bad.  Some groundwork is needed to fix
this well.

This change is expected to be a significant win on NUMA, where most
page allocation comes from the local node's zones.

For NUMA the `struct zone' itself should really be placed in that
node's memory, which is something the platform owners should look at.
However the internode cache will help here.

Per-node kswapd would make heaps of sense too.

Replace the global page LRUs with per-zone LRUs.

This fixes the failure described at
http://mail.nl.linux.org/linux-mm/2002-08/msg00049.html

It will also fixes the problem wherein a search for a reclaimable
ZONE_NORMAL page will undesirably move aged ZONE_HIGHMEM pages to the
head of the inactive list.  (I haven't tried to measure any benefit
from this aspect).

It will also reduces the amount of CPU spent scanning pages in page
reclaim. I haven't instrumented this either.

This is a minimal conversion - the aging and reclaim logic is left
unchanged, as far as is possible.

I was bitten by the "incremental min" logic in __alloc_pages again.
There's a state in which the sum-of-mins exceeds zone->pages_high.  So
we call into try_to_free_pages(), which does nothing at all (all zones
have free_pages > pages_high).  The incremental min is unchanged and
the VM locks up.

This was fixed in __alloc_pages: if zone->free_pages is greater than
zone->pages_high then just go and grab a page.

- Remove the zonelist_t typedef.  Rename struct zonelist_struct to
struct zonelist and use that everywhere.

- Remove the zone_t typedef.  Rename struct zone_struct to struct
zone and use that everywhere.

Don't align the buffer_head slab on hardware cacheline boundaries.
It's on the wrong side of the speed/space tradeoff, especially for
P4's.

It has been noticed that across a kernel build many calls to
tlb_flush_mmu() do not have anything to flush, apparently because glibc
is mmapping a file over a previously-mapped region which has no
faulted-in ptes.

This patch detects this case and optimises away a little over one third
of the tlb invalidations.

The functions which potentially cause an invalidate are
tlb_remove_tlb_entry(), pte_free_tlb() and pmd_free_tlb().  These have
been front-ended in asm-generic/tlb.h and the per-arch versions now
have leading double-underscores.  The generic versions tag the
mmu_gather_t as needing a flush and then call the arch-specific
version.

tlb_flush_mmu() looks at tlb->need_flush and if it sees that no real
activity has happened, the invalidation is avoided.

The success rate is displayed in /proc/meminfo for the while.  This
should be removed later.

- Kill duplicate debug check

- Add a test for pages which have a pte_chain coming off the buddy lists.