headers
Henrique de Moraes Holschuh | 1 Feb 2009 02:25
Picon
Favicon

Re: marching through all physical memory in software

On Sat, 31 Jan 2009, Pavel Machek wrote:
> > You can also implement software-based ECC using a background scrubber
> > and setting aside pages to store the ECC information.  Now, THAT is
> > probably not worth bothering with due to the performance impact, but
> > who knows...
> 
> Actually, that would be quite cool. a) I suspect memory in  my zaurus
> bitrots and b) bitroting memory over s2ram is apprently quite common.

Well, software-based ECC for s2ram (calculate right before s2ram,
check-and-fix right after waking up) is certainly doable and a LOT
easier than my crazy idea of sofware-based generic ECC (which requires
some sort of trick to detect pages that were written to, so that you
can update their ECC information)...

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Daniel Lowengrub | 1 Feb 2009 12:19
Picon

Re: [PATCH 2.6.28 1/2] memory: improve find_vma

On 1/29/09, Ingo Molnar <mingo <at> elte.hu> wrote:
> Here's an mmap performance tester:
>
>    http://redhat.com/~mingo/misc/mmap-perf.c
>
> maybe that shows a systematic effect. If you've got a Core2 based
> test-system then you could try perfstat as well, for much more precise
> instruction counts. (can give you more info about how to do that if you
> have such a test-system.)
>
>        Ingo
>
I compiled mmap-perf.c an ran it with ./mmap-perf 1 (not as root, does
that matter?).  As obvious from the code, the output that I got was
the final state of the /proc/[self]/maps file.  How does this
information tell me about performance?  Anyhow, here're the first 10
lines of the [heap] part of the output using the standard kernel:
0965b000-0967c000 rw-p 0965b000 00:00 0          [heap]
86007000-86009000 rw-p 86007000 00:00 0
86009000-8600a000 ---p 86009000 00:00 0
86018000-8601b000 rw-p 86018000 00:00 0
8601c000-86023000 -w-p 8601c000 00:00 0
86023000-86026000 rw-p 86023000 00:00 0
86026000-86029000 r--p 86026000 00:00 0
8603e000-86040000 rw-p 8603e000 00:00 0
86048000-8604c000 r--p 86048000 00:00 0
8604f000-86054000 ---p 8604f000 00:00 0
and here're the first 10 lines of the output with the patch applied:
09596000-095b7000 rw-p 09596000 00:00 0          [heap]
860ab000-860ad000 rw-p 860ab000 00:00 0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Molnar | 1 Feb 2009 14:00
Picon
Picon
Favicon

Re: [PATCH 2.6.28 1/2] memory: improve find_vma


* Daniel Lowengrub <lowdanie <at> gmail.com> wrote:

> On 1/29/09, Ingo Molnar <mingo <at> elte.hu> wrote:
> > Here's an mmap performance tester:
> >
> >    http://redhat.com/~mingo/misc/mmap-perf.c
> >
> > maybe that shows a systematic effect. If you've got a Core2 based
> > test-system then you could try perfstat as well, for much more precise
> > instruction counts. (can give you more info about how to do that if you
> > have such a test-system.)
> >
> >        Ingo
> >
> I compiled mmap-perf.c an ran it with ./mmap-perf 1 (not as root, does
> that matter?).  As obvious from the code, the output that I got was
> the final state of the /proc/[self]/maps file.  How does this
> information tell me about performance?  Anyhow, here're the first 10
> lines of the [heap] part of the output using the standard kernel:
> 0965b000-0967c000 rw-p 0965b000 00:00 0          [heap]
> 86007000-86009000 rw-p 86007000 00:00 0
> 86009000-8600a000 ---p 86009000 00:00 0
> 86018000-8601b000 rw-p 86018000 00:00 0
> 8601c000-86023000 -w-p 8601c000 00:00 0
> 86023000-86026000 rw-p 86023000 00:00 0
> 86026000-86029000 r--p 86026000 00:00 0
> 8603e000-86040000 rw-p 8603e000 00:00 0
> 86048000-8604c000 r--p 86048000 00:00 0
> 8604f000-86054000 ---p 8604f000 00:00 0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zhang, Yanmin | 2 Feb 2009 04:38
Picon

Re: [patch] SLQB slab allocator

Hi, Hugh,

On Fri, 2009-01-23 at 14:23 +0000, Hugh Dickins wrote:
> On Thu, 22 Jan 2009, Hugh Dickins wrote:
> > On Thu, 22 Jan 2009, Pekka Enberg wrote:
> > > On Wed, Jan 21, 2009 at 8:10 PM, Hugh Dickins <hugh <at> veritas.com> wrote:
> > > >
> > > > That's been making SLUB behave pretty badly (e.g. elapsed time 30%
> > > > more than SLAB) with swapping loads on most of my machines.  Though
Would you like to share your tmpfs loop swap load with me, so I could reproduce
it on my machines? Do your machines run at i386 mode or x86-64 mode? How much
memory do your machines have?

> > > > oddly one seems immune, and another takes four times as long: guess
> > > > it depends on how close to thrashing, but probably more to investigate
> > > > there.  I think my original SLUB versus SLAB comparisons were done on
> > > > the immune one: as I remember, SLUB and SLAB were equivalent on those
> > > > loads when SLUB came in, but even with boot option slub_max_order=1,
> > > > SLUB is still slower than SLAB on such tests (e.g. 2% slower).
> > > > FWIW - swapping loads are not what anybody should tune for.
> > > 
> > > What kind of machine are you seeing this on? It sounds like it could
> > > be a side-effect from commit 9b2cd506e5f2117f94c28a0040bf5da058105316
> > > ("slub: Calculate min_objects based on number of processors").
As I know little about your workload, I just guess from 'loop swap load' that
your load eats memory quickly and kernel/swap is started to keep a low free
memory.

Commit 9b2cd506e5f2117f94c28a0040bf5da058105316 is just a method to increase
the page order for slub so there more free objects available in a slab. That
(Continue reading)

Permalink | Reply | 0 comments |
headers
MinChan Kim | 2 Feb 2009 07:16
Picon

[PATCH] fix mlocked page counter mismatch

When I tested following program, I found that mlocked counter 
is strange. 
It couldn't free some mlocked pages of test program.

It is caused that try_to_unmap_file don't check real 
page mapping in vmas. 
That's because goal of address_space for file is to find all processes 
into which the file's specific interval is mapped. 
What I mean is that it's not related page but file's interval.

Even if the page isn't really mapping at the vma, it returns 
SWAP_MLOCK since the vma have VM_LOCKED, then calls 
try_to_mlock_page. After all, mlocked counter is increased again. 

This patch is based on 2.6.28-rc2-mm1.

-- my test program --

#include <stdio.h>
#include <sys/mman.h>
int main()
{
        mlockall(MCL_CURRENT);
        return 0;
}

-- before --

root <at> barrios-target-linux:~# cat /proc/meminfo | egrep 'Mlo|Unev'
Unevictable:           0 kB
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Enberg | 2 Feb 2009 10:00
Picon
Picon
Favicon
Gravatar

Re: [patch] SLQB slab allocator

Hi Yanmin,

On Mon, 2009-02-02 at 11:38 +0800, Zhang, Yanmin wrote:
> Can we add a checking about free memory page number/percentage in function
> allocate_slab that we can bypass the first try of alloc_pages when memory
> is hungry?

If the check isn't too expensive, I don't any reason not to. How would
you go about checking how much free pages there are, though? Is there
something in the page allocator that we can use for this?

		Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
MinChan Kim | 2 Feb 2009 11:17
Picon

[BUG??] Deadlock between kswapd and sys_inotify_add_watch(lockdep report)

Nick's new lockdep of 'annotate reclaim context(__GFP_NOFS)' reported following message.
In my kernel(2.6.28-rc2-mm1 + nick's patch : http://patchwork.kernel.org/patch/4251/),

During 'dd if=/dev/zero of=test.image bs=4096 count=2621440' of two processes,
following message occured. 

I think it might be useful case of 'annotate reclaim context'. 

[  331.718116] =================================
[  331.718120] [ INFO: inconsistent lock state ]
[  331.718124] 2.6.28-rc2-mm1-lockdep #6
[  331.718126] ---------------------------------
[  331.718129] inconsistent {ov-reclaim-W} -> {in-reclaim-W} usage.
[  331.718133] kswapd0/218 [HC0[0]:SC0[0]:HE0:SE1] takes:
[  331.718136]  (&inode->inotify_mutex){--..+.}, at: [<c01dba70>] inotify_inode_is_dead+0x20/0x90
[  331.718148] {ov-reclaim-W} state was registered at: 
[  331.718150]   [<c01532ee>] mark_held_locks+0x3e/0x90
[  331.718157]   [<c015338e>] lockdep_trace_alloc+0x4e/0x80
[  331.718162]   [<c01acee6>] kmem_cache_alloc+0x26/0xf0
[  331.718166]   [<c0243fa0>] idr_pre_get+0x50/0x70
[  331.718172]   [<c01db761>] inotify_handle_get_wd+0x21/0x60
[  331.718176]   [<c01dc012>] inotify_add_watch+0x52/0xe0
[  331.718181]   [<c01dcca8>] sys_inotify_add_watch+0x148/0x170
[  331.718185]   [<c0104032>] syscall_call+0x7/0xb
[  331.718190]   [<ffffffff>] 0xffffffff
[  331.718205] irq event stamp: 1288446
[  331.718207] hardirqs last  enabled at (1288445): [<c0179695>] call_rcu+0x75/0x90
[  331.718213] hardirqs last disabled at (1288446): [<c0370103>] mutex_lock_nested+0x53/0x2f0
[  331.718221] softirqs last  enabled at (1284622): [<c0132fa2>] __do_softirq+0x132/0x180
[  331.718226] softirqs last disabled at (1284617): [<c0133079>] do_softirq+0x89/0x90
(Continue reading)

Permalink | Reply | 0 comments |
headers
MinChan Kim | 2 Feb 2009 11:25
Picon

Re: [BUG??] Deadlock between kswapd and sys_inotify_add_watch(lockdep report)

But, I am not sure whether it's real bug or not.
I always suffer from reading lockdep report's result. :(
It would be better to have a document about lockdep report analysis.
--

-- 
Kinds regards,
MinChan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Peter Zijlstra | 2 Feb 2009 11:40
Favicon

Re: [BUG??] Deadlock between kswapd and sys_inotify_add_watch(lockdep report)

On Mon, 2009-02-02 at 19:25 +0900, MinChan Kim wrote:
> But, I am not sure whether it's real bug or not.

Me neither, inode life-times are tricky, but on first sight it looks
real enough.

> I always suffer from reading lockdep report's result. :(
> It would be better to have a document about lockdep report analysis.

I've never found them hard to read, so I'm afraid you'll have to be more
explicit about what is unclear to you.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
MinChan Kim | 2 Feb 2009 12:27
Picon

Re: [BUG??] Deadlock between kswapd and sys_inotify_add_watch(lockdep report)

On Mon, Feb 02, 2009 at 11:40:02AM +0100, Peter Zijlstra wrote:
> On Mon, 2009-02-02 at 19:25 +0900, MinChan Kim wrote:
> > But, I am not sure whether it's real bug or not.
> 
> Me neither, inode life-times are tricky, but on first sight it looks
> real enough.
> 
> > I always suffer from reading lockdep report's result. :(
> > It would be better to have a document about lockdep report analysis.
> 
> I've never found them hard to read, so I'm afraid you'll have to be more
> explicit about what is unclear to you.

It's becuase not lockdep humble report but my poor knowledge. :(
Could you elaborate please ?

>[  331.718120] [ INFO: inconsistent lock state ]
>[  331.718124] 2.6.28-rc2-mm1-lockdep #6
>[  331.718126] ---------------------------------
>[  331.718129] inconsistent {ov-reclaim-W} -> {in-reclaim-W} usage.
                                         ^                 ^ 
                                        write ?           write ?
>
>[  331.718133] kswapd0/218 [HC0[0]:SC0[0]:HE0:SE1] takes:
                            ^^^^^^^^^^^^^^^^^^^^^^
                            what means ? HC,SC,HE,SE
>
>[  331.718136]  (&inode->inotify_mutex){--..+.}, at: [<c01dba70>] inotify_inode_is_dead+0x20/0x90
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane