On Mon, 27 Aug 2007, Andrew Morton wrote:
On Mon, 27 Aug 2007 21:37:14 +0100 (BST)
Hugh Dickins [EMAIL PROTECTED] wrote:
So I agree with the patch, but not with its description.
I don't see which part of the description you disagree with, but please
do improve it if you can.
I'd
On Tue, 28 Aug 2007, Ingo Molnar wrote:
this commit:
commit d243769d3f83b318813a04a9592bb7cfedc6c280
Author: Hugh Dickins [EMAIL PROTECTED]
Date: Mon Aug 27 16:06:19 2007 +0100
fix bogus hotplug cpu warning
Fix bogus DEBUG_PREEMPT warning on x86_64, when cpu brought online
On Wed, 29 Aug 2007, Alexey Dobriyan wrote:
On Wed, Aug 29, 2007 at 01:35:57AM +0200, Michal Piotrowski wrote:
On 28/08/07, Alexey Dobriyan [EMAIL PROTECTED] wrote:
Every time I try to boot with maxcpus=1 it dies show_stat():
Is this a regression?
yep
A regression since when, I
On Wed, 29 Aug 2007, Daniel Drake wrote:
I've spent some time trying to understand why swapoff is such a slow
operation.
My experiments show that when there is not much free physical memory,
swapoff moves pages out of swap at a rate of approximately 5mb/sec. When
there is a lot of free
On Wed, 29 Aug 2007, Arjan van de Ven wrote:
On Wed, 29 Aug 2007 09:29:32 -0400
Daniel Drake [EMAIL PROTECTED] wrote:
I've spent some time trying to understand why swapoff is such a slow
operation.
My experiments show that when there is not much free physical memory,
swapoff moves
On Wed, 29 Aug 2007, Oliver Neukum wrote:
Am Mittwoch 29 August 2007 schrieb Arjan van de Ven:
Another question, if this is during system shutdown, maybe that's a
valid case for flushing most of the pagecache first (from userspace)
since most of what's there won't be used again anyway. If
On Wed, 29 Aug 2007, Hugh Dickins wrote:
On Wed, 29 Aug 2007, Alexey Dobriyan wrote:
On Wed, Aug 29, 2007 at 01:35:57AM +0200, Michal Piotrowski wrote:
On 28/08/07, Alexey Dobriyan [EMAIL PROTECTED] wrote:
Every time I try to boot with maxcpus=1 it dies show_stat
On Thu, 30 Aug 2007, Eric W. Biederman wrote:
There is one other possibility. Typically the swap code is using
compatibility disk I/O functions instead of the best the kernel
can offer. I haven't looked recently but it might be worth just
making certain that there isn't some low-level
On Thu, 30 Aug 2007, Roman Zippel wrote:
I've noticed an oddity with CONFIG_HOTPLUG_CPU in 2.6.23-rc:
make oldconfig seems to turn it on even when nothing wants it,
increasing kernel size by about 10k; but if you then edit the
line out of .config and make oldconfig again, it
On Thu, 30 Aug 2007, Rafael J. Wysocki wrote:
On Thursday, 30 August 2007 14:40, Hugh Dickins wrote:
I wonder what config options this might have forced in the past.
Probably CONFIG_SUSPEND, which was a new option, defaulted to 'y' and
selected CONFIG_HOTPLUG_CPU indirectly, because
for now and just revert those #ifndef CONFIG_HOTPLUG_CPU
optimizations in rc1's commit.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.23-rc4/init/main.c 2007-08-28 04:42:58.0 +0100
+++ linux/init/main.c 2007-08-30 20:45:26.0 +0100
@@ -397,10 +397,6 @@ static void __init
Two issues in this mail, sorry if I'd have done better to separate them.
One: Thinkpad T43p suspend-to-RAM regression.
Verily, what Len giveth with one hand, he taketh away with the other.
Henrique's fix to CONFIG_THINKPAD_ACPI_INPUT_ENABLED default is now in,
thanks, so Fn-F4 ought now to
On Tue, 14 Aug 2007, Alexey Starikovskiy wrote:
Sergey Dolgov wrote:
On Mon, Aug 13, 2007 at 07:44:48PM +0100, Hugh Dickins wrote:
Git bisection (with manual fixups to i386 mmiocfg horror, thanks
for drawing attention to that in your changelog) accuses Alexey's
ACPI: EC: If ECDT
-implement-swap-prefetching.patch in 2.6.23-rc2-mm1. We could add a
fix to the latter, but I think it's better to adjust Nick's, so that
it's right for whichever tree it's in: move the responsibility to
SetPageLocked from read_swap_cache_async to add_to_swap_cache.
Signed-off-by: Hugh Dickins
and the
filesystems use that instead of saying -unsignedlong, perhaps they should
use a cast or a long or an s64. I don't know, but here's this for now...
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
include/linux/percpu_counter.h | 13 +
1 file changed, 9 insertions(+), 4
as
the same bit as ATA_DFLAG_PIO. Here's a hotfix against top of -rc2-mm2.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
include/linux/libata.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 2.6.23-rc2-mm2/include/linux/libata.h 2007-08-10 12:14:36.0
+0100
On Tue, 9 Oct 2007, Nick Piggin wrote:
by it ;) To prove my point: the *first* approach I posted to fix this
problem was exactly a patch to special-case the zero_page refcounting
which was removed with my PageReserved patch. Neither Hugh nor yourself
liked it one bit!
True (speaking for me; I
On Thu, 11 Oct 2007, Ryan Finnie wrote:
On 10/11/07, Andrew Morton [EMAIL PROTECTED] wrote:
shit. That's a nasty bug. Really userspace should be testing for -1, but
the msync() library function should only ever return 0 or -1.
Does this fix it?
--- a/mm/page-writeback.c~a
+++
On Sat, 13 Oct 2007, Pekka Enberg wrote:
On 10/12/07, Hugh Dickins [EMAIL PROTECTED] wrote:
But I keep suspecting that the answer might be the patch below (which
rather follows what drivers/block/rd.c is doing). I'm especially
worried that, rather than just AOP_WRITEPAGE_ACTIVATE being
When updating this IBM ThinkPad T43p from 2.6.22 to 2.6.23-rc1
using make oldconfig, the text and default Y of
config THINKPAD_ACPI_INPUT_ENABLED
bool Enable input layer support by default
depends on THINKPAD_ACPI
default y
---help---
Enables hot key
On Wed, 1 Aug 2007, Michael S. Tsirkin wrote:
Hi!
ACPI appears to have been broken with 2.6.23-rc1 on my T60
Userspace from ubuntu dapper.
(Whereas I'm using a T43p with openSUSE 10.2.)
1. During boot, I see a lot of messages like this:
[ 41.034204] acpi LNXSYSTM:00: uevent:
On Mon, 30 Jul 2007, Jan Blunck wrote:
Introduce white-out support to tmpfs.
Signed-off-by: Jan Blunck [EMAIL PROTECTED]
---
include/linux/shmem_fs.h |1
mm/shmem.c | 54
+++
2 files changed, 55 insertions(+)
I see
On Wed, 1 Aug 2007, Henrique de Moraes Holschuh wrote:
On Wed, 01 Aug 2007, Michael S. Tsirkin wrote:
Forcing the selection at compile-time isn't such a great idea IMHO.
Isn't there a way to support both old and new userspace?
It only afects the *defaults* of various driver knobs that can
on a different cpu: so need to reevaluate it.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.21-rc7-mm1/mm/slub.c2007-04-24 20:26:48.0 +0100
+++ linux/mm/slub.c 2007-04-25 15:49:12.0 +0100
@@ -1234,11 +1234,12 @@ have_slab:
page = new_slab(s, gfpflags, node
On Wed, 25 Apr 2007, Christoph Lameter wrote:
On Wed, 25 Apr 2007, Hugh Dickins wrote:
SLUB gave me a NULL pointer dereference in slab_alloc(), in the
slab_lock(page) of its Current cpuslab is acceptable block: cpu
1 had been looking at cpu_slab[2], which then went NULL beneath
On Wed, 25 Apr 2007, Christoph Lameter wrote:
On Wed, 25 Apr 2007, Hugh Dickins wrote:
Right. local_irq_save does not switch off preemption as I thought.
Strange comment. Preemption is not possible while IRQs are disabled,
but new_slab() rightly reenables them within itself
On Fri, 27 Apr 2007, Nick Piggin wrote:
But that's because of ia64's cache coherency implementation. I don't really
follow the documentation to know whether it should be one way or the other,
but surely it should be done either before or after the set_pte_at, not both.
Anyway, how about
On Sat, 28 Apr 2007, Nick Piggin wrote:
OIC, you need a virtual address to evict the icache, so you can't
flush at flush_dcache time? Or does ia64 have an instruction to
flush the whole icache? (it would be worth testing, to see how much
performance suffers).
I'm puzzled by that remark: the
On Fri, 27 Apr 2007, Andrew Morton wrote:
hm, could do. might_sleep() is intertwined with preempt in complex ways,
but we did decouple that at the config level. no_mmap_sem() will dtrt for
all preempt settings.
But I'll be keeping this as a -mm-only debug patch (which brings us up to
On Fri, 27 Apr 2007, Rohit Seth wrote:
On Fri, 2007-04-27 at 15:18 +0100, Hugh Dickins wrote:
Right. Extra flush_icache_page routines will add cost to archs that
have non-null definition of this routine. BTW, isn't flush_icache_page
marked for deprecation?
Yes, flush_icache_page is marked
On Sat, 28 Apr 2007, Andrew Morton wrote:
It seems wildly screwed up that we have a PageReserved() page with a pfn of
zero (!) which claims to be in a reiserfs mapping, only it isn't attached
to a reiserfs file. How the heck did that happen?
It's simply that it somehow got a spurious page
On Wed, 6 Apr 2005, Nick Piggin wrote:
Don't use PF_*. That namespace is already being used by at least
process flags and protocol flags. Maybe page_locked, page_dirty,
etc. might be better
Much better. But...
Lastly, it is quite likely that many people will consider this to be
more
instead, a hack in mmap.c to derive one from t'other.
This patch fixes the bugs, the remaining patches just clean it up.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/mmap.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
--- 2.6.12-rc2-mm1/mm/mmap.c2005-04-05 15
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no
other syscall refers to it), unnecessary (sys_mincore loops over vmas
further down) and incorrect (misses user addresses in ARM's first pgd).
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/mincore.c |3 ---
1
ARM define FIRST_USER_ADDRESS as PAGE_SIZE (beyond the machine vectors
when they are mapped low), and use that definition in place of locally
defined MIN_MAP_ADDR.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
arch/arm/kernel/sys_arm.c | 11 ++-
include/asm-arm/pgtable.h |7
,
and FIRST_USER_ADDRESS would then have to be determined at runtime.
Let's fix it at PAGE_SIZE throughout the architecture.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
arch/arm26/kernel/sys_arm.c |9 -
include/asm-arm26/pgtable.h |7 +++
2 files changed, 11 insertions(+), 5
Once all the MMU architectures define FIRST_USER_ADDRESS,
remove hack from mmap.c which derived it from FIRST_USER_PGD_NR.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/mmap.c |5 -
1 files changed, 5 deletions(-)
--- 2.6.12-rc2-mm1+/mm/mmap.c 2005-04-05 18:59:01.0
Replace misleading definition of FIRST_USER_PGD_NR 0 by definition of
FIRST_USER_ADDRESS 0 in all the MMU architectures beyond arm and arm26.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
include/asm-alpha/pgtable.h |2 +-
include/asm-cris/pgtable.h |2 +-
include/asm-frv
On Fri, 8 Apr 2005, Nick Piggin wrote:
David Howells wrote:
Hugh Dickins [EMAIL PROTECTED] wrote:
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent
(no
other syscall refers to it), unnecessary (sys_mincore loops over vmas
further down) and incorrect (misses user
On Thu, 7 Apr 2005, Andi Kleen wrote:
Dave Jones wrote:
I realised today that this happens every time X starts up for
the first time. I did some experiments, and found that with 2.6.12rc1
it's gone. Either it got fixed accidentally, or its hidden now
by one of the many changes in
On Thu, 14 Apr 2005, Andi Kleen wrote:
Thanks for the analysis. However I doubt the load_cr3 patch can fix
it. All it does is to stop the CPU from prefetching mappings (which
can cause different problem).
I thought that the leave_mm code (before your patch) flushes the TLB, but
restores cr3
On Fri, 15 Apr 2005, Chris Wright wrote:
* Andi Kleen ([EMAIL PROTECTED]) wrote:
On Thu, Apr 14, 2005 at 11:27:12AM -0700, Chris Wright wrote:
Yes, I've seen it in .11 and earlier kernels. Happen to have same
x86_64 string on my bad pmd dumps, but can't reproduce it at all.
So, for
On Tue, 19 Apr 2005, Andi Kleen wrote:
On Fri, Apr 15, 2005 at 06:58:20PM +0100, Hugh Dickins wrote:
I must confess, with all due respect to Andi, that I don't understand his
dismissal of the possibility that load_cr3 in leave_mm might be the fix
(to create_elf_tables writing user stack
/truncate_count sequence. For varying reasons, other users
of shmem_getpage can't go beyond i_size, so just add it to shmem_nopage.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.11-rc3/mm/shmem.c 2005-02-03 09:06:16.0 +
+++ linux/mm/shmem.c2005-02-05 16:52
of any scenario in which that could happen now.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.11-rc3/mm/truncate.c2005-02-03 09:06:16.0 +
+++ linux/mm/truncate.c 2005-02-03 17:26:40.0 +
@@ -45,7 +45,6 @@ static inline void truncate_partial_page
static void
On Fri, 4 Feb 2005, Anton Altaparmakov wrote:
On Thu, 2005-02-03 at 11:23 -0800, Bryan Henderson wrote:
I think the point is that we can't have a handler for writes, because
the writes are being done by simple CPU Store instructions in a user
program. The handler we're talking about
On Thu, 3 Feb 2005, IWAMOTO Toshihiro wrote:
The current implementation of memory hotremoval relies on that pages
can be unmapped from process spaces. After successful unmapping,
subsequent accesses to the pages are blocked and don't interfere
the hotremoval operation.
However, this code
On Mon, 7 Feb 2005, Hugh Dickins wrote:
On Thu, 3 Feb 2005, IWAMOTO Toshihiro wrote:
The current implementation of memory hotremoval relies on that pages
can be unmapped from process spaces. After successful unmapping,
subsequent accesses to the pages are blocked and don't interfere
On Tue, 8 Feb 2005, Chris Wright wrote:
* Mark F. Haigh ([EMAIL PROTECTED]) wrote:
If security_vm_enough_memory() fails there, then we vm_unacct_memory()
that we never accounted (if security_vm_enough_memory() fails, no memory
is accounted).
You missed one subtle point. That failure
On Wed, 9 Feb 2005, Chris Wright wrote:
* Hugh Dickins ([EMAIL PROTECTED]) wrote:
dup_mmap's charge starts out at 0 and gets added to each time around
the loop through vmas; if security_vm_enough_memory fails at any point
in that loop, we need to vm_unacct_memory the charge already
On Thu, 10 Feb 2005, Andrea Arcangeli wrote:
The reason pinned pages cannot be unmapped is that if they're being
unmapped while a rawio read is in progress, a cow on some shared
swapcache under I/O could happen.
If a try_to_unmap + COW over a shared swapcache happens during a rawio
read,
On Thu, 10 Feb 2005, Andrea Arcangeli wrote:
On Thu, Feb 10, 2005 at 08:19:47PM +, Hugh Dickins wrote:
get_user_pages broke COW in advance of the I/O. The reason for
subsequent COW if the page gets unmapped is precisely because
can_share_swap_page used page_count to judge
On Fri, 11 Feb 2005, Andrea Arcangeli wrote:
Ok, I'm quite convinced it's correct now. The only thing that can make
mapcount go up without the lock on the page without userspace
intervention (and userspace intervention would make it an undefined
behaviour like in my example with fork), was
a page fault would hit the BUG in its nopage.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.11-rc3-bk8/mm/madvise.c 2004-12-24 21:36:31.0 +
+++ linux/mm/madvise.c 2005-02-11 19:07:35.0 +
@@ -8,7 +8,7 @@
#include linux/mman.h
#include linux/pagemap.h
#include linux
On Fri, 11 Feb 2005, Richard F. Rebel wrote:
I can't seem to find clear documentation about the 'share' column
from /proc/pid/statm.
Does this include pages that are shared with forked children marked as
copy-on-write?
Does this only reflect libraries that are dynamically loaded? What
On Sat, 12 Feb 2005, Richard F. Rebel wrote:
That said, many mod_perl users are *VERY* interested in being able to
detect and observe how shared our forked children are. Shared meaning
private pages shared with children (copy on write). Is it even possible
to do this in 2.6 kernels? If
On Mon, 14 Feb 2005, Andrea Arcangeli wrote:
By the way, while we're talking of remove_exclusive_swap_page:
a more functional issue I sometimes wonder about, why don't we
remove_exclusive_swap_page on write fault? Keeping the swap slot
is valuable if read fault, but once the page is
On Tue, 15 Feb 2005, Andrea Arcangeli wrote:
On Tue, Feb 15, 2005 at 11:51:52AM +0100, Andi Kleen wrote:
It's not just for cosmetic reasons that I suggest to change this. My
point is that the _real_ reason why we had the bug in the first place is
that people forgets that p-size includes the
On Wed, 16 Feb 2005, Erik de Castro Lopo wrote:
The problem is triggered by a user space application which
mmaps memory space on a custom PCI card via /dev/mem, reads
some data and munmaps it. The program works perfectly on a
2.4.26 kernel. On 2.6.10 I get this on the console:
kernel
On Wed, 16 Feb 2005, Mauricio Lin wrote:
Well, for each vma it is checked how many pages are mapped to rss. So
I have to check per page if it is allocated in physical memory. I know
that this is a heavy function, but do you have any suggestion to
improve this? What do you mean needs
On Wed, 16 Feb 2005, Mauricio Lin wrote:
Thanks by your suggestion. I did not know that kernel 2.4.29 has
changed the statm implementation. As I can see the statm
implementation is different between 2.4 and 2.6.
Let me see if I can use the 2.4.29 statm idea to improve the smaps for
kernel
On Wed, 16 Feb 2005, Richard F. Rebel wrote:
I have heard that this particular information, while very important to
userland developers like me, is probably too expensive to keep track of
for most users.
Perhaps a way to enable it for developers, whom are willing to spend the
cpu cycles,
to write protect the pte, mprotect back and forth could be
used to reinstate write permission without going through page_mkwrite.
No explicit change to those: deal with it by using the vm_page_prot
of a private mapping on any shared mapping which has a page_mkwrite.
Signed-off-by: Hugh Dickins
.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/memory.c | 35 +++
1 files changed, 23 insertions(+), 12 deletions(-)
--- 2.6.13-rc2-mm2/mm/memory.c 2005-07-07 12:33:21.0 +0100
+++ linux/mm/memory.c 2005-07-11 20:01:28.0 +0100
@@ -1968,27
that
separation less than helpful. And page_cache_get on the old_page before
page_table_lock is dropped - nothing else stabilizes the page in there.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
[I sent this out an hour and a half ago, but it still hasn't appeared,
whereas 2/3 and 3/3 did: let's try again
that
separation less than helpful. And page_cache_get on the old_page before
page_table_lock is dropped - nothing else stabilizes the page in there.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/memory.c | 113 +++-
1 files changed, 51 insertions
On Mon, 25 Jul 2005, Michael S. Tsirkin wrote:
This patch adds PROT_DONTCOPY to mmap and mprotect, to set VM_DONTCOPY on vma.
This is needed for infiniband userspace i/o, where we need to protect against
- the child process accessing the parent hardware page
- the parent registered
On Mon, 4 Jul 2005, Christoph Hellwig wrote:
On Sun, Jul 03, 2005 at 01:30:23PM +0100, Hugh Dickins wrote:
this way we don't need to put a lot of __slow's in the code *and* it's
based on measurements not assumptions, and can be tuned for a specific
situation in addition
On Thu, 7 Jul 2005, Andrew Morton wrote:
[EMAIL PROTECTED] wrote:
Looks like it's been stable for 4 months?
yup, although I don't think it's been used much.
Just a sidenote to say I should be sending you an update to it
(the /proc/$pid/smaps code) in the next couple of days, but merely
Here comes a series of 13 swap patches, mainly to mm/swapfile.c, based
on 2.6.13-rc2-mm1 but applying also to 2.6.13-rc2. I don't think any
of them are important enough for 2.6.13, though the first half are
straightforward. The main thrust is to scan the swap_map lockless,
to stop the infamous
Update swap extents comment: nowadays we guard with S_SWAPFILE not i_sem.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swapfile.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 2.6.13-rc2-mm1/mm/swapfile.c2005-07-07 12:33:21.0 +0100
+++ swap1/mm
was safe, but likewise move it earlier, before taking the locks (once
try_to_unuse has completed, nothing can be needing the swap extents).
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swapfile.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- swap2/mm/swapfile.c 2005-07-08
:
not worth doing so, but ensure nr_badpages is 0 for a regular swapfile.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swapfile.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
--- swap1/mm/swapfile.c 2005-07-08 19:13:21.0 +0100
+++ swap2/mm
, and let map_swap_page search the list forwards: profiles
shows it to be twice as quick that way - because prefetch works better
on how the structs are typically kmalloc'ed? or because usually more
is written to than read from swap, and swap is allocated ascendingly?
Signed-off-by: Hugh Dickins
Rewrite scan_swap_map to allocate in just the same way as before
(taking the next free entry SWAPFILE_CLUSTER-1 times, then restarting at
the lowest wholly empty cluster, falling back to lowest entry if none),
but with a view towards dropping the lock in the next patch.
Signed-off-by: Hugh
a regression in swap_duplicate, then probably we
should add a hashlock for the swap_map entries alone (shorts being
anatomic), so as to help the case of the single swap device too.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
Documentation/vm/locking | 15 ++---
include/linux/swap.h | 11
Aha, swsusp dips into swap_info[], better update it to swap_lock. It's
bitflipping flags with 0xFF, so get_swap_page will allocate from only
the one chosen device: let's change that to flip SWP_WRITEOK.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
kernel/power/swsusp.c | 12
This makes negligible difference in practice: but swap_list.next should not
be updated to a higher prio in the general helper swap_info_get, but rather
in swap_entry_free; and then only in the case when entry is actually freed.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swapfile.c
The get_swap_page/scan_swap_map latency can be so bad that even those
without preemption configured deserve relief: periodically cond_resched.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swapfile.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
--- swap10/mm
swap_device_lock as well as swap_list_lock to clear SWP_WRITEOK. Reduces
lock contention when there are parallel swap devices of the same priority.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swapfile.c | 73 +++---
1 files changed, 35
, so save a little space by keeping it on stack.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
include/linux/swap.h |1 -
mm/swapfile.c| 44 ++--
2 files changed, 30 insertions(+), 15 deletions(-)
--- swap4/include/linux/swap.h 2005-07-08
The swap header's unsigned int last_page determines the range of swap
pages, but swap_info has been using int or unsigned long in some cases:
use unsigned int throughout (except, in several places a local unsigned
long is useful to avoid overflows when adding).
Signed-off-by: Hugh Dickins [EMAIL
.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
include/linux/swap.h |2 ++
mm/swapfile.c| 42 +++---
2 files changed, 37 insertions(+), 7 deletions(-)
--- swap9/include/linux/swap.h 2005-07-08 19:14:26.0 +0100
+++ swap10/include
-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/rmap.c |7 +--
1 files changed, 1 insertion(+), 6 deletions(-)
--- 2.6.13-rc2-mm1/mm/rmap.c2005-07-07 12:33:21.0 +0100
+++ linux/mm/rmap.c 2005-07-09 01:20:41.0 +0100
@@ -290,8 +290,6 @@ static int page_referenced_one(struct pa
Three of the four BUG_ONs in delete_from_swap_cache are immediately
repeated in __delete_from_swap_cache: delete those and add the one.
But perhaps mm/ is altogether overprovisioned with historic BUGs?
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/swap_state.c |6 +-
1 files
/proc/$pid/smaps show_smap has followed show_map in using variable name
map where we would usually say vma: change them to vma throughout.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 98 ++---
1 files changed, 49
to hack on this example, so better limit its still poor latency.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 150 -
1 files changed, 58 insertions(+), 92 deletions(-)
--- smaps1/fs/proc/task_mmu.c 2005-07-09 02:14
Sorry, some parentheses around my SWP_WRITEOK check would help.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
kernel/power/swsusp.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- swap13/kernel/power/swsusp.c2005-07-08 19:15:59.0 +0100
+++ swap14/kernel/power
/proc/$pid/smaps should be reporting in kB not KB
(and pray that this doesn't start another kibibytes war ;)
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
--- smaps2/fs/proc/task_mmu.c 2005-07-09 02
dup_mmap of a VM_DONTCOPY vma forgot to lower the child's total_vm. (But
no way does this account for the recent report of total_vm seen too low.)
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
kernel/fork.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- 2.6.13-rc2-mm1
.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- 2.6.13-rc2-mm2/mm/shmem.c 2005-07-06 11:23:52.0 +0100
+++ linux/mm/shmem.c2005-07-12 13:58:26.0 +0100
@@ -668,6 +668,7 @@ static void shmem_delete_inode(struct in
struct shmem_inode_info *info = SHMEM_I(inode
On Sun, 13 Mar 2005, Arjan van de Ven wrote:
\
+ if ((lock)-break_lock) \
+ (lock)-break_lock = 0; \
}
On Wed, 16 Mar 2005, Chris Wright wrote:
* Max Kamenetsky ([EMAIL PROTECTED]) wrote:
I've been seeing the following bug lately when running some memory- and
CPU-intensive MATLAB jobs. MATLAB hangs, and commands like ps and top
no longer work. The only solution I've found is to reboot.
On Sat, 19 Mar 2005, hib2743 wrote:
I have seen discussion about this in recent months on the list, and
unfortunately I am experiencing the same problem myself now on a new
machine. I have run memtest86 for some hours and there seems to be no
problem. The machine has 1GB DDR PC3200 RAM/AMD
On Mon, 21 Mar 2005, Andi Kleen wrote:
Bodo Eggert [EMAIL PROTECTED] writes:
atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
(I'm using a keyboard switch and a IBM PS/2 keyboard)
This one should be just taken out. It is as far as I can figure out
completely useless
While dabbling here in mmap.c, clean up mysterious mpnts to vmas.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/mmap.c | 35 +--
1 files changed, 17 insertions(+), 18 deletions(-)
--- freepgt4/mm/mmap.c 2005-03-21 19:06:48.0 +
+++ freepgt5
scanned, but that's just debug
which hasn't been useful in a while; and if we want the map_count 0 on
exit check back, it can easily come from the final remove_vm_struct loop.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
include/asm-ia64/processor.h |8
include/asm-ppc64/processor.h
** in the
public interfaces, since we might want to add latency lockdrops later;
but no attempt to do so yet, going by vma should itself reduce latency.
But what if is_hugepage_only_range? Those ia64 and ppc64 cases need
careful examination: put that off until a later patch of the series.
Signed-off-by: Hugh
cannot join a hugepage_only_range
to any other (safe to join huges? probably but don't bother).
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
arch/ia64/mm/hugetlbpage.c | 29 +++--
arch/ppc64/mm/hugetlbpage.c | 10 --
include/asm-ia64/page.h |2
,end check
Fix placing of free_p?d_range's check for addr against end.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
--- freepgt5/mm/memory.c2005-03-22 04:28:40.0 +
+++ freepgt6/mm/memory.c2005-03-22 05:11:05.0 +
@@ -127,11 +127,6 @@ static inline void
301 - 400 of 4042 matches
Mail list logo
