into home.transmeta.com:/home/torvalds/v2.5/linux

The kallsyms patches added __kallsyms as last section into vmlinux,
behind .bss.

This was done to save two additional kallsyms passes, since as the
added section was last, it did not change the symbols before it.

With the new infrastructure in the top-level Makefile, we do not need
to do full relinks for these passes, so they are cheaper. We now
use one additional link/kallsyms run to be able to place the __kallsyms
section before .bss. The other pass is saved by adding an empty but 
allocated __kallsyms section in kernel/kallsyms.c, so the first kallsyms
pass already generates a section of the final size.

kallsyms needs to actually have a final vmlinux to extract the symbols,
and then add this information as a new section to the final vmlinux.

Currently, we basically just do the vmlinux link twice, adding
.tmp_kallsyms.o the second time. However, it's actually possible to just
link together the temporary vmlinux generated the first time and the
new object file directly without going back to all the single parts
that the temporary vmlinux was linked from.

This mechanism should be useful for sparc as well, where the btfix
mechanism needs an already linked vmlinux, too.

IMPORTANT: This does only work as desired if the link script can be
used recursively, i.e.

ld <flags> -T arch/$(ARCH)/vmlinux.lds.s -o vmlinux.test vmlinux

generates a vmlinux.test which is identical to vmlinux.
arch/i386/vmlinux.lds.S needed a little tweaking, so probably the
other archs do as well.

into tp1.ruhr-uni-bochum.de:/home/kai/src/kernel/v2.5/linux-2.5.make

We don't descend anymore when building vmlinux, so don't do so for
the i386 specific boot targets, either.

Plus, more cleanup in arch/i386/Makefile

Reported by Peter Osterlund.

(Yeah, the real fix would be to make driver services not have to
know about low-level pcmcia core drivers beforehand, but that's not
life as we know it right now).

into home.transmeta.com:/home/torvalds/v2.5/linux

This fixes the build error that occurs if you have a certain selection
of module/modversions settings.

The PCMCIA layer claims the IO or memory regions for all cards.  This
means that any port registered via 8250_cs must not cause the 8250
code to claim the resources itself.

We also add support for iomem-based ports at initialisation time for
PPC.

Improve the warning messages when using obsolete features, kill one
remaining user of $(list-multi)

(by Sam Ravnborg)

I also made O_TARGET != built-in.o an error, since compatibility code for
that case has already been dropped 

into home.transmeta.com:/home/torvalds/v2.5/linux

Hardly anything uses this function, so the debug checks in there are
not of much value.

The check for bdev_readonly() should be done in submit_bio().

Local variable `major' was altogether unused.

The ratelimiting logic in balance_dirty_pages_ratelimited() is designed
to prevent excessive calls to the expensive get_page_state(): On a big
machine we only check to see if we're over dirty memory limits once per
1024 dirtyings per cpu.

This works OK normally, but it has the effect of allowing each process
to go 1024 pages over the dirty limit before it gets throttled.

So if someone runs 16000 tiobench threads, they can go 16G over the
dirty memory threshold and die the death of buffer_head consumption.
Because page dirtiness pins the page's buffer_heads, defeating the
special buffer_head reclaim logic.

I'd left this overshoot artifact in place because it provides a degree
of adaptivity - of someone if running hundreds of dirtying processes
(dbench!) then they do want to overshoot the dirty memory limit.

But it's hard to balance, and is really not worth the futzing around.
So change the logic to only perform the get_page_state() call rate
limiting if we're known to be under the dirty memory threshold.

The patch removes page->virtual for all architectures which do not
define WANT_PAGE_VIRTUAL.  Hash for it instead.

Possibly we could define WANT_PAGE_VIRTUAL for CONFIG_HIGHMEM4G, but it
seems unlikely.

A lot of the pressure went off kmap() and page_address() as a result of
the move to kmap_atomic().  That should be the preferred way to address
CPU load in the set_page_address() and page_address() hashing and
locking.

If kmap_atomic is not usable then the next best approach is for users
to cache the result of kmap() in a local rather than calling
page_address() repeatedly.

One heavy user of kmap() and page_address() is the ext2 directory code.

On a 7G Quad PIII, running four concurrent instances of

	while true
	do
		find /usr/src/linux > /dev/null
	done

on ext2 with everything cached, profiling shows that the new hashed
set_page_address() and page_address() implementations consume 0.4% and
1.3% of CPU time respectively.   I think that's OK.

This is the replacement for write_mapping_buffers().

Whenever the mpage code sees that it has just written a block which had
buffer_boundary() set, it assumes that the next block is dirty
filesystem metadata.  (This is a good assumption - that's what
buffer_boundary is for).

So we do a lookup in the blockdev mapping for the next block and it if
is present and dirty, then schedule it for IO.

So the indirect blocks in the blockdev mapping get merged with the data
blocks in the file mapping.

This is a bit more general than the write_mapping_buffers() approach.
write_mapping_buffers() required that the fs carefully maintain the
correct buffers on the mapping->private_list, and that the fs call
write_mapping_buffers(), and the implementation was generally rather
yuk.

This version will "just work" for filesystems which implement
buffer_boundary correctly.  Currently this is ext2, ext3 and some
not-yet-merged reiserfs patches.  JFS implements buffer_boundary() but
does not use ext2-like layouts - so there will be no change there.

Works nicely.

When the global buffer LRU was present, dirty ext2 indirect blocks were
automatically scheduled for writeback alongside their data.

I added write_mapping_buffers() to replace this - the idea was to
schedule the indirects close in time to the scheduling of their data.

It works OK for small-to-medium sized files but for large, linear writes
it doesn't work: the request queue is completely full of file data and
when we later come to scheduling the indirects, their neighbouring data
has already been written.

So writeback of really huge files tends to be a bit seeky.

So.  Kill it.  Will fix this problem by other means.

From Badari Pulavarty.

Rather than allocating maximum-sized BIOs, use the new
bio_get_nr_vecs() hint when sizing the BIOs.

Also keep track of the approximate upper-bound on the number of pages
remaining to do, so we can again avoid allocating excessively-sized
BIOs.

By Vincent Hanquez <tab@tuxfamily.org>

Use the bio_get_nr_pages() hint for sizing the BIOs which writeback
allocates.

The page reclaim logic will bail out if all zones are at pages_high.
But if the caller is requesting a higher-order allocation we need to go
on and free more memory anyway.  That's the only way we have of
addressing buddy fragmentation.