Andrew Morton [Sat, 12 Apr 2003 19:59:04 +0000 (12:59 -0700)]
[PATCH] vmalloc stats in /proc/meminfo
From: Matt Porter <porter@cox.net>
There was a thread a while back on lkml where Dave Hansen proposed this
simple vmalloc usage reporting patch. The thread pretty much died out as
most people seemed focused on what VM loading type bugs it could solve. I
had posted that this type of information was really valuable in debugging
embedded Linux board ports. A common example is where people do arch
specific setup that limits there vmalloc space and then they find modules
won't load. ;) Having the Vmalloc* info readily available is real useful in
helping folks to fix their kernel ports.
Andrew Morton [Sat, 12 Apr 2003 19:58:42 +0000 (12:58 -0700)]
[PATCH] /proc/interrupts allocates too much memory
From: David Mosberger <davidm@napali.hpl.hp.com>
interrupts_open() can easily try to kmalloc() more memory than
supported by kmalloc. E.g., with 16KB page size and NR_CPUS==64, it
would try to allocate 147456 bytes.
The workaround below is to allocate 4KB per 8 CPUs. Not really a
solution, but the fundamental problem is that /proc/interrupts
shouldn't use a fixed buffer size in the first place. I suppose
another solution would be to use vmalloc() instead. It all feels like
bandaids though.
Andrew Morton [Sat, 12 Apr 2003 19:57:41 +0000 (12:57 -0700)]
[PATCH] architecture hooks for mem_map initialization
From: Christoph Hellwig <hch@lst.de>
This patch is from the IA64 tree, with minor cleanups from me.
Split out initialization of pgdat->node_mem_map into a separate function
and allow architectures to override it. This is needed for HP IA64
machines that have a virtually mapped memory map to support big
memory holes without having to use discontigmem.
(memmap_init_zone is non-static to allow the IA64 code to use it -
I did that instead of passing it's address into the arch hook as
it is done currently in the IA64 tree)
Andrew Morton [Sat, 12 Apr 2003 19:57:13 +0000 (12:57 -0700)]
[PATCH] bootmem speedup from the IA64 tree
From: Christoph Hellwig <hch@lst.de>
This patch is from the IA64 tree, with some minor cleanups by me.
David described it as:
This is a performance speed up and some minor indendation fixups.
The problem is that the bootmem code is (a) hugely slow and (b) has
execution that grow quadratically with the size of the bootmap bitmap.
This causes noticable slowdowns, especially on machines with (relatively)
large holes in the physical memory map. Issue (b) is addressed by
maintaining the "last_success" cache, so that we start the next search
from the place where we last found some memory (this part of the patch
could stand additional reviewing/testing). Issue (a) is addressed by
using find_next_zero_bit() instead of the slow bit-by-bit testing.
Andrew Morton [Sat, 12 Apr 2003 19:55:43 +0000 (12:55 -0700)]
[PATCH] don't clear PG_uptodate on ENOSPC
If get_block() returns -ENOSPC __block_write_full_page() is currently
clearing PG_uptodate.
Tht doesn't make any sense - failure to allocate space (or an IO error) does
not make the page not uptodate. It will create pages which are dirty, mapped
into pagetables and not uptodate, which is a nonsensical state.
Andrew Morton [Sat, 12 Apr 2003 19:55:21 +0000 (12:55 -0700)]
[PATCH] Fix deadlock with ext3+quota
From: Jan Kara <jack@ucw.cz>
Fixes a deadlock-causing lock-ranking bug between dqio_sem and
journal_start().
It sets up the needed infrastructure so that the quota code's sync_dquot()
operation can call into ext3 and arrange for the transaction start to be
nested outside the taking of dqio_sem.
Andrew Morton [Sat, 12 Apr 2003 19:55:02 +0000 (12:55 -0700)]
[PATCH] Remove flush_page_to_ram()
From: Hugh Dickins <hugh@veritas.com>
This patch removes the long deprecated flush_page_to_ram. We have
two different schemes for doing this cache flushing stuff, the old
flush_page_to_ram way and the not so old flush_dcache_page etc. way:
see DaveM's Documentation/cachetlb.txt. Keeping flush_page_to_ram
around is confusing, and makes it harder to get this done right.
All architectures are updated, but the only ones where it amounts
to more than deleting a line or two are m68k, mips, mips64 and v850.
I followed a prescription from DaveM (though not to the letter), that
those arches with non-nop flush_page_to_ram need to do what it did
in their clear_user_page and copy_user_page and flush_dcache_page.
Dave is consterned that, in the v850 nb85e case, this patch leaves its
flush_dcache_page as was, uses it in clear_user_page and copy_user_page,
instead of making them all flush icache as well. That may be wrong:
I'm just hesitant to add cruft blindly, changing a flush_dcache macro
to flush icache too; and naively hope that the necessary flush_icache
calls are already in place. Miles, please let us know which way is
right for v850 nb85e - thanks.
Andrew Morton [Sat, 12 Apr 2003 19:54:20 +0000 (12:54 -0700)]
[PATCH] radix_tree_delete API improvement
radix_tree_delete() currently returns 0 on success, -ENOENT if there was
nothing to delete.
But it is more useful to return the address of the deleted item on success
and NULL if there was no matching item. It can potentially save a
lookup+delete operation.
George Anzinger [Fri, 11 Apr 2003 14:09:44 +0000 (07:09 -0700)]
[PATCH] too much timer simplification...
Noted by David Mosberger:
"If someone happens to arm a periodic timer at exactly 256 jiffies (as
ohci happens to do on platforms with HZ=1024), then you end up getting
an endless loop of timer activations, causing a machine hang.
The problem is that __run_timers updates base->timer_jiffies _before_
running the callback routines. If a callback re-arms the timer at
exactly 256 jiffies, add_timers() will reinsert the timer into the list
that we're currently processing, which of course will cause the timer to
expire immediately again, etc., etc., ad naseum... "
The answer here is to move the whole expired list to a local header and
to not look back.
Ben Collins [Fri, 11 Apr 2003 11:38:49 +0000 (04:38 -0700)]
[PATCH] IEEE-1394/Firewire updates
- Convert nodemgr to new driver model.
- Convert to new module_param() calls.
- Merged fixes for devfs mkdir and some sleep-in-atomic fixes from
mainline 2.5-bk
- Fix possible memory corruption on highlevel local read/write.
- Fix bitmap usage for some bitops.
- Fix bug in closing ISO stream.
- Fixes for nodemgr probing in the event of a reset storm.
- Workaround for nForce2 firewire chipset. This is preliminary.
- Conversion of SBP-2 to use new driver model in nodemgr, including
providing a driver for firewire unit directories and registering
proper callbacks.
Make sure to kunmap() the right address in fs/nfs/dir.c.
Found by Rik van Riel:
"There's a serious bug in the handling of the pointer returned
by kmap_atomic() in nfs/dir.c. The pointer (part of desc) is
passed into find_dirent_name and from there into dir_decode,
which modifies the pointer.
That means you end up passing a wrong address to kunmap_atomic()."
Dave Jones [Thu, 10 Apr 2003 03:39:21 +0000 (04:39 +0100)]
[AGPGART] x86-64 Kconfig fixes.
Offering the K7 GARTs on 64bit kernels causes sillyness, like reports of
"unrecognised device, try unsupported". We don't want people to even try
that, so don't offer it in the first place.
There's really no good reason for offering any of the IA32 era GARTs on a
x86-64 64bit kernel. If Intel (or whoever) ever do an x86-64 clone, a new
gart driver will be started anyways, as has been done for amd-k8-agp.
Dave Jones [Thu, 10 Apr 2003 02:15:13 +0000 (03:15 +0100)]
[AGPGART] Remove CONFIG_AGP3.
This optioned saved just a handful of bytes, and uglied up the code
quite a lot. Saving less than a page of memory is not as important as
maintainable code.
Paul Mackerras [Wed, 9 Apr 2003 10:29:50 +0000 (03:29 -0700)]
[PATCH] i2c: Add driver for powermac keywest i2c interface
Here is a patch that adds an i2c bus driver for the i2c interface
found in the "KeyWest" and later combo-I/O chips used in powermacs.
The patch is against Linus' current BK tree.
[PATCH] USB speedtouch: don't open a connection if no firmware
How about this one instead. MOD_INC_USE_COUNT is placed before I call
any functions that can sleep. Let's just hope that the call to me doesn't
come after some sleeping in the higher layers...
projects / linux / log