Bill Huey | 1 Mar 07:22 2003

Re: kernel BUG at mm/memory.c:757! (2.5.62-mjb2)

On Sat, Feb 22, 2003 at 07:50:48PM -0800, Bill Huey wrote:
> > Feb 22 04:02:08 gnuppy kernel:  ------------[ cut here ]------------
> > Feb 22 04:02:08 gnuppy kernel: kernel BUG at mm/memory.c:757!
> > Feb 22 04:02:08 gnuppy kernel: invalid operand: 0000
> > Feb 22 04:02:08 gnuppy kernel: CPU:    0
> > Feb 22 04:02:08 gnuppy kernel: EIP:    0060:[unmap_all_pages+757/832] Tainted: PF 
> > Feb 22 04:02:08 gnuppy kernel: EFLAGS: 00210202
> > Feb 22 04:02:08 gnuppy kernel: EIP is at unmap_all_pages+0x2f5/0x340
> > Feb 22 04:02:08 gnuppy kernel: eax: 00000001   ebx: 0f7a8067   ecx: d612c360   edx: c039f4a0
> > Feb 22 04:02:08 gnuppy kernel: esi: c0000000   edi: d1152ffc   ebp: d122ff58   esp: d122fed8
> > Feb 22 04:02:08 gnuppy kernel: ds: 007b   es: 007b   ss: 0068
> > Feb 22 04:02:08 gnuppy kernel: Process xchat (pid: 743, threadinfo=d122e000 task=d12512a0)
> > Feb 22 04:02:08 gnuppy kernel: Stack: d122ff0c 00000000 00000010 d12512a0 c126b240 c0000000 c0000000
c0000000 
> > Feb 22 04:02:08 gnuppy kernel:        0000000c c12ab4d0 d1971c00 d1971c00 00000000 c1289920 c1274318
c12765a0 
> > Feb 22 04:02:08 gnuppy kernel:        c12b7190 c1267de8 c1269cb0 c126b9e8 c126a098 c128a320 c126acf0
c126af98 
> > Feb 22 04:02:08 gnuppy kernel: Call Trace:
> > Feb 22 04:02:08 gnuppy kernel:  [exit_mmap+24/224] exit_mmap+0x18/0xe0
> > Feb 22 04:02:08 gnuppy kernel:  [mmput+85/176] mmput+0x55/0xb0
> > Feb 22 04:02:08 gnuppy kernel:  [do_exit+273/768] do_exit+0x111/0x300
> > Feb 22 04:02:08 gnuppy kernel:  [do_group_exit+123/192] do_group_exit+0x7b/0xc0
> > Feb 22 04:02:08 gnuppy kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
> > Feb 22 04:02:08 gnuppy kernel: 
> > Feb 22 04:02:08 gnuppy kernel: Code: 0f 0b f5 02 9f ab 34 c0 b8 00 e0 ff ff 8b 55 08 21 e0 8b 00 
> > Feb 22 04:02:11 gnuppy kernel:  ------------[ cut here ]------------
> 
> I just found out that it could likely be related to the NVidia driver module
> from Rik van Riel. Ooops.
(Continue reading)

matt | 1 Mar 15:08 2003

matt sent you a card from NiceCards!

Dear lse-tech,

Guess what?  matt (matt <at> devplug.org) has sent you a greeting card!

Your card can be picked up by going to our card pick-up page at:

http://nicecards.com/

and entering in the following card ID: 4121130-FXMPQ

Thank you!

team <at> nicecards.com
NiceCards

Note: Your card will be kept in our card center for two weeks.  After two
weeks, your card will be deleted.

====================================================================
Try out these other great sites in the NiceCards network!

    http://friendfinder.com - Dating and friendship personals
    http://asiafriendfinder.com - Chinese personals
    http://frenchfriendfinder.com - French personals
    http://koreanfriendfinder.com - Korean personals
    http://germanfriendfinder.com - German personals
    http://amigos.com - Spanish personals
    http://seniorfriendfinder.com - Senior personals
    http://churchfriendfinder.com - Christian/spiritual personals
    http://adultfriendfinder.com - Adults only personals
(Continue reading)

Martin J. Bligh | 1 Mar 15:47 2003

Re: kernel BUG at mm/memory.c:757! (2.5.62-mjb2)

>> I just found out that it could likely be related to the NVidia driver module
>> from Rik van Riel. Ooops.
> 
> Again, correction, I get a tons of these even without the NVidia driver
> module, so that's not the problem.
> 
> This problem is still pretty live unfortunately. Fixed in the new patchset ?
> 
> The problem doesn't seems fatal and the machine doesn't crash hard, but it's
> still a bug.

OK, this looks like the exit speedup stuff, which is removed in 63-mjb2,
could you retry with that? 

Thanks,

M.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Martin J. Bligh | 1 Mar 20:17 2003

Re: [PATCH] New dcache / inode hash tuning patch


--On Friday, February 28, 2003 23:32:32 +0100 Andi Kleen <ak <at> suse.de> wrote:

>>  fs/dcache.c: In function `dcache_seq_show':
>> fs/dcache.c:1675: warning: long unsigned int format, unsigned int arg (arg 3)
>> make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
>> fs/built-in.o(.text+0x164da): In function `dcache_seq_next':
>> : undefined reference to `__divdi3'
>> make: *** [.tmp_vmlinux1] Error 1
> 
> I only tested on x86-64 sorry which has 64bit division of course.
> 
> Just casting the *pos in dcache_seq_next to u32 should do the trick as we 
> don't care about large file support for that file

OK, that fixed it - thanks. Pretty much equivalent, if anything, it's
a tad slower, but hardly measurable.

Kernbench-2: (make -j N vmlinux, where N = 2 x num_cpus)
                              Elapsed        User      System         CPU
              2.5.63-mjb2       44.43      557.16       95.31     1467.83
        2.5.63-mjb2-andi2       44.34      556.89       96.60     1473.33

Kernbench-16: (make -j N vmlinux, where N = 16 x num_cpus)
                              Elapsed        User      System         CPU
              2.5.63-mjb2       45.39      560.26      117.25     1492.33
        2.5.63-mjb2-andi2       45.50      559.74      118.44     1490.00

DISCLAIMER: SPEC(tm) and the benchmark name SDET(tm) are registered
trademarks of the Standard Performance Evaluation Corporation. This 
(Continue reading)

Andi Kleen | 1 Mar 20:30 2003
Picon

Re: [PATCH] New dcache / inode hash tuning patch

On Sat, Mar 01, 2003 at 11:17:31AM -0800, Martin J. Bligh wrote:
> 
> 
> --On Friday, February 28, 2003 23:32:32 +0100 Andi Kleen <ak <at> suse.de> wrote:
> 
> >>  fs/dcache.c: In function `dcache_seq_show':
> >> fs/dcache.c:1675: warning: long unsigned int format, unsigned int arg (arg 3)
> >> make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
> >> fs/built-in.o(.text+0x164da): In function `dcache_seq_next':
> >> : undefined reference to `__divdi3'
> >> make: *** [.tmp_vmlinux1] Error 1
> > 
> > I only tested on x86-64 sorry which has 64bit division of course.
> > 
> > Just casting the *pos in dcache_seq_next to u32 should do the trick as we 
> > don't care about large file support for that file
> 
> OK, that fixed it - thanks. Pretty much equivalent, if anything, it's
> a tad slower, but hardly measurable.

Is that comparing to the previous patch or straight 2.5.63 ? 

If it's "only in the noise slower" I would consider it a win already
because it uses much less memory than the old code.

-Andi

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
(Continue reading)

Martin J. Bligh | 1 Mar 20:37 2003

Re: [PATCH] New dcache / inode hash tuning patch

>> >>  fs/dcache.c: In function `dcache_seq_show':
>> >> fs/dcache.c:1675: warning: long unsigned int format, unsigned int arg (arg 3)
>> >> make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
>> >> fs/built-in.o(.text+0x164da): In function `dcache_seq_next':
>> >> : undefined reference to `__divdi3'
>> >> make: *** [.tmp_vmlinux1] Error 1
>> > 
>> > I only tested on x86-64 sorry which has 64bit division of course.
>> > 
>> > Just casting the *pos in dcache_seq_next to u32 should do the trick as we 
>> > don't care about large file support for that file
>> 
>> OK, that fixed it - thanks. Pretty much equivalent, if anything, it's
>> a tad slower, but hardly measurable.
> 
> Is that comparing to the previous patch or straight 2.5.63 ? 
> 
> If it's "only in the noise slower" I would consider it a win already
> because it uses much less memory than the old code.

Was 63-mjb2 vs 63-mjb2+your new patch (ie nothing touching the old
patch). Is it possible to split out the shrinkage from the new cache
algorithm? Maybe we should auto-tune sizes based on the amount of mem
in the machine or something ?

M.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
(Continue reading)

Martin J. Bligh | 1 Mar 20:44 2003

Re: [PATCH] New dcache / inode hash tuning patch

>>> OK, that fixed it - thanks. Pretty much equivalent, if anything, it's
>>> a tad slower, but hardly measurable.
>> 
>> Is that comparing to the previous patch or straight 2.5.63 ? 
>> 
>> If it's "only in the noise slower" I would consider it a win already
>> because it uses much less memory than the old code.
> 
> Was 63-mjb2 vs 63-mjb2+your new patch (ie nothing touching the old
> patch). Is it possible to split out the shrinkage from the new cache
> algorithm? Maybe we should auto-tune sizes based on the amount of mem
> in the machine or something ?

Oh, I forgot to include the diff (+ worse with your patch, - better)

       252     1.5% total
       235     5.0% default_idle
        71     9.2% d_lookup
        34     2.4% do_anonymous_page
        27    17.8% path_lookup
        23     0.0% d_hash
        17     3.7% vm_enough_memory
        10    11.1% link_path_walk
        10     7.0% do_schedule
        10    22.7% do_page_cache_readahead
...
       -10   -13.0% do_wp_page
       -14    -6.8% file_move
       -35   -12.8% __fput
       -96    -4.5% .text.lock.file_table
(Continue reading)

Andi Kleen | 1 Mar 20:47 2003
Picon

Re: [PATCH] New dcache / inode hash tuning patch

> Was 63-mjb2 vs 63-mjb2+your new patch (ie nothing touching the old
> patch). Is it possible to split out the shrinkage from the new cache
> algorithm? Maybe we should auto-tune sizes based on the amount of mem
> in the machine or something ?

I would prefer to only have CONFIG_SMALL (very small hash table
for embedded stuff etc.) and the normal 64-128K hash table (64K =16K
buckets) More memory in the machine doesn't usually mean more cache, and 
it is as well a cache size thing.

Your experiments seem to suggest that the 64K table performs similar
to the 1MB table that plain 2.5.63 uses on your box. I was toying
with the idea of increasing it to 128K, need to benchmark that, but
definitely not above that because 256K on 64bit machines would 
be already excessive.

-Andi

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Andi Kleen | 1 Mar 20:48 2003
Picon

Re: [PATCH] New dcache / inode hash tuning patch

> Oh, I forgot to include the diff (+ worse with your patch, - better)
> 
>        252     1.5% total
>        235     5.0% default_idle
>         71     9.2% d_lookup

That's probably noise then. 

-Andi

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Martin J. Bligh | 1 Mar 20:49 2003

Re: [PATCH] New dcache / inode hash tuning patch

>>>> OK, that fixed it - thanks. Pretty much equivalent, if anything, it's
>>>> a tad slower, but hardly measurable.
>>> 
>>> Is that comparing to the previous patch or straight 2.5.63 ? 
>>> 
>>> If it's "only in the noise slower" I would consider it a win already
>>> because it uses much less memory than the old code.
>> 
>> Was 63-mjb2 vs 63-mjb2+your new patch (ie nothing touching the old
>> patch). Is it possible to split out the shrinkage from the new cache
>> algorithm? Maybe we should auto-tune sizes based on the amount of mem
>> in the machine or something ?
> 
> Oh, I forgot to include the diff (+ worse with your patch, - better)
> 
>        252     1.5% total
>        235     5.0% default_idle
>         71     9.2% d_lookup
>         34     2.4% do_anonymous_page
>         27    17.8% path_lookup
>         23     0.0% d_hash
>         17     3.7% vm_enough_memory
>         10    11.1% link_path_walk
>         10     7.0% do_schedule
>         10    22.7% do_page_cache_readahead
> ...
>        -10   -13.0% do_wp_page
>        -14    -6.8% file_move
>        -35   -12.8% __fput
>        -96    -4.5% .text.lock.file_table
(Continue reading)


Gmane