Add id for v850 `nb85e_uart' to serial_core.h

Give a compile-time error on the v850 if MAX_ORDER is too large

Make the v850 leds driver's seek routine always return a value

Update make variable used by initramfs `binary blob' creation on v850

Change the default baud rate of the `nb85e_uart' driver to 115200

Tweak some v850 name strings
[basically only affects printed output]

Random whitespace tweaks in v850 files

Add my name to CREDITS file

Update includes in v850 files to reflect recent header changes

Update v850 to use kstat_cpu in irqs.c

The v850 doesn't need sys_old_getrlimit

Add TASK_UNMAPPED_BASE for v850

Update v850 usage of do_fork to supply new args

Add v850 support for initramfs

Random minor fixes for v850 `anna' platform

Update `nb85e_uart' driver for recent serial framework changes

Make NB85E_UART_CKSR_MAX_FREQ (in nb85e_uart driver) overridable
[The proper value is CPU-dependent]

Add v850 nanosecond stat fields

Add support for AS85EP1 platform to v850 arch

Add v850 versions of dump_stack and show_stack
Also move v850 show_regs to same source file (bug.c)

Add v850 support for new module loader

Add asm macros on v850 so the size of asm data objects can be recorded
[This just makes it easier to see the sizes using readelf or whatever]

Fix some minor type problems in v850 code
[Mostly signed/unsigned mismatches]

Consolidate various v850 platform banner printks

cpu_buffer.c needs errno.h for ENOMEM.

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

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

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/lsm-tree

That annoying ldm message is just debugging output somebody forgot to
remove.

into kroah.com:/home/greg/linux/BK/lsm-2.5

into groveronline.com:/root/bk/linux-acpi

into groveronline.com:/root/bk/linux-acpi

Shrinking a huge number of dentries or inodes can hold dcache_lock or
inode_lock for a long time.  Not only does this hold off preemption -
holding those locks basically shuts down the whole VFS.

A neat fix for all such caches is to chunk the work up at the
shrink_slab() level.

I made the chunksize pretty small, for scalability reasons - avoid
holding the lock for too long so another CPU can come in, acquire it
and go off to do some work.

Running sync_blockdev() inside lock_kernel causes long scheduling
stalls under some conditions because the lock_kernel() disables
preemption.

We don't need the BKL across sync_blockdev(), so move it down a bit.

This is a minimal fix - we probably don't need BKL for much at all in
there.

When the VM is under heavy load and a page allocator caller is holding
the BKL there can be several-millisecond scheduling stalls.

So add a cond_resched() at every 32nd page (approx).

From Hugh.  Remove some strangeness in the swapoff path.

"it dates from the days when that block set *swap_map to 0, but in
 2.4.13 I changed it to set *swap_map to 1 and delete_from_swap_cache
 afterwards: it's been wrong ever since, hasn't it?  swap_list_locking
 can go, it was there to guard nr_swap_pages for si_swapinfo; the
 swap_device_locking has to stay because swap_map is an array of
 unsigned _shorts_."

There are a couple of statistical functions which scan the entire swap
map counting things up, to display in /proc.

On my machine, these hold spinlocks for 19 milliseconds which is
unacceptable from a scheduling latency point of view.

And an application which sits in a loop reading /proc/swaps on a large
machine is probably a decent denial-of-service attack - it will limit
swap allocations to tens of pages per second.

So add a counter to swap_info_struct and use it to track how many pages
are currently in use, so those reporting functions don't need to add
them all up.

This is the first in a little batch of patches which address long-held
locks in the VFS/MM layer which are affecting our worst-case scheduling
latency, and are making CONFIG_PREEMPT not very useful.

We end up with a worst-case of 500 microseconds at 500MHz, which is
very good.  Unless you do an exit with lots of mmapped memory.
unmap_page_range() needs work.

Some of these patches also add rescheduling points for non-preemptible
kernels - where I felt that the code path could be long enough to be
perceptible.



Three places in the generic pagecache functions need manual
rescheduling points even for non-preemptible kernels:

- generic_file_read()  (Can hold the CPU for seconds)

- generic_file_write() (ditto)

- filemap_fdatawait().  This won't hold the CPU for so long, but it
  can walk many thousands of pages under the lock.  It needs a lock
  drop and scheduling point for both preemptible and non-preemptible
  kernels.  (This one's a bit ugly...)

pdflush writes back chunks of ~1000 pages.  It currently takes a short
nap if it writes back no pages at all.  That could cause it to write
back lots of small batches of pages, as it bounces against a congested
queue.

Change it to sleep if it failed to write back the entire batch against
a congested queue.  Ths reduces the context switch rate a little.

The context switch rate is still fairly high (150/sec) - this appears
to be due to add_disk_randomness() scheduling a work function.

Patch from Bill Irwin.  It has the potential to break userspace
monitoring tools a little bit, and I'm a rater uncertain about
how useful the per-process per-cpu accounting is.

Bill sent this out as an RFC on July 29:

"These statistics severely bloat the task_struct and nothing in
 userspace can rely on them as they're conditional on CONFIG_SMP.  If
 anyone is using them (or just wants them around), please speak up."

And nobody spoke up.

If we apply this, the contents of /proc/783/cpu will go from

	cpu  1 1
	cpu0 0 0
	cpu1 0 0
	cpu2 1 1
	cpu3 0 0

to

	cpu  1 1

And we shall save 256 bytes from the ia32 task_struct.

On my SMP build with NR_CPUS=32:

Without this patch, sizeof(task_struct) is 1824, slab uses a 1-order
allocation and we are getting 2 task_structs per page.

With this patch, sizeof(task_struct) is 1568, slab uses a 2-order
allocation and we are getting 2.5 task_structs per page.

So it seems worthwhile.

(Maybe this highlights a shortcoming in slab.  For the 1824-byte case
it could have used a 0-order allocation)