[LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4

[LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4

[Diwakar Sharma (RBEI/ECF3)]

Hi,

I was getting the max_map_count test failed. It looked to me failing at filter_map function. The platform I'm working on is an i686 architecture running on Virtualbox.
I added below additional macro condition and it's passing now. I want to understand if not including i686/386 was intentional originally for some reason? Also vdso part I added additionaly.

#elif defined(__i686__) || defined(__i386__)
static int filter_map(char *line)
{
        char buf[BUFSIZ];
        int ret;

        ret = sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf);
        if (ret != 1)
                return 0;

        return ((strcmp(buf, "[vdso]") == 0) | (strcmp(buf, "[vsyscall]") == 0));
}


On another similar architecture (but the actual h/w board), the same code gives messages like "4096 map entries in total, but expected 4096 entries" and reported FAIL, implying map_count and max_maps is same ( Contrary to map_count==max_maps+1 ). How do we analyze this scenario? Does this mean it is not exceeding by one for sysctl setting? How to verify that.


Thanks and Regards
Diwakar Sharma



------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4

[Stanislav Kholmanskikh]

On 05/05/2014 10:52 AM, Diwakar Sharma (RBEI/ECF3) wrote:
> Hi,

Hi!

>
> I was getting the max_map_count test failed. It looked to me failing at filter_map function. The platform I'm working on is an i686 architecture running on Virtualbox.
> I added below additional macro condition and it's passing now. I want to understand if not including i686/386 was intentional originally for some reason? Also vdso part I added additionaly.
>
> #elif defined(__i686__) || defined(__i386__)
> static int filter_map(char *line)
> {
>          char buf[BUFSIZ];
>          int ret;
>
>          ret = sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf);
>          if (ret != 1)
>                  return 0;
>
>          return ((strcmp(buf, "[vdso]") == 0) | (strcmp(buf, "[vsyscall]") == 0));
> }
>
>
> On another similar architecture (but the actual h/w board), the same code gives messages like "4096 map entries in total, but expected 4096 entries" and reported FAIL, implying map_count and max_maps is same ( Contrary to map_count==max_maps+1 ). How do we analyze this scenario? Does this mean it is not exceeding by one for sysctl setting? How to verify that.
>

Which kernel version do you use? I want to check this test case in my 
environment.

Thanks.

PS: Also look at this thread 
http://sourceforge.net/p/ltp/mailman/ltp-list/thread/52009D26.4030609%40oracle.com/

>
> Thanks and Regards
> Diwakar Sharma
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4

[Diwakar Sharma (RBEI/ECF3)]

Hello,

I am using 3.8.13.21

oracle-virtualbox:/usr/lib# uname -r
3.8.13.21

Thanks and Regards
Diwakar Sharma



-----Original Message-----
From: Stanislav Kholmanskikh [mailto:stanislav.kholmanskikh@oracle.com] 
Sent: Monday, May 05, 2014 6:32 PM
To: Diwakar Sharma (RBEI/ECF3); ltp-list@lists.sourceforge.net
Subject: Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4



On 05/05/2014 10:52 AM, Diwakar Sharma (RBEI/ECF3) wrote:
> Hi,

Hi!

>
> I was getting the max_map_count test failed. It looked to me failing at filter_map function. The platform I'm working on is an i686 architecture running on Virtualbox.
> I added below additional macro condition and it's passing now. I want to understand if not including i686/386 was intentional originally for some reason? Also vdso part I added additionaly.
>
> #elif defined(__i686__) || defined(__i386__)
> static int filter_map(char *line)
> {
>          char buf[BUFSIZ];
>          int ret;
>
>          ret = sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf);
>          if (ret != 1)
>                  return 0;
>
>          return ((strcmp(buf, "[vdso]") == 0) | (strcmp(buf, "[vsyscall]") == 0));
> }
>
>
> On another similar architecture (but the actual h/w board), the same code gives messages like "4096 map entries in total, but expected 4096 entries" and reported FAIL, implying map_count and max_maps is same ( Contrary to map_count==max_maps+1 ). How do we analyze this scenario? Does this mean it is not exceeding by one for sysctl setting? How to verify that.
>

Which kernel version do you use? I want to check this test case in my 
environment.

Thanks.

PS: Also look at this thread 
http://sourceforge.net/p/ltp/mailman/ltp-list/thread/52009D26.4030609%40oracle.com/

>
> Thanks and Regards
> Diwakar Sharma
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4

[Stanislav Kholmanskikh]

On 05/05/2014 05:06 PM, Diwakar Sharma (RBEI/ECF3) wrote:
> Hello,
>
> I am using 3.8.13.21
>
> oracle-virtualbox:/usr/lib# uname -r
> 3.8.13.21

Hmm, max_map_count passes with vanilla kernel 3.8.13 and the current LTP 
git version:

[root@ol6-i386 tunable]# uname -a
Linux ol6-i386 3.8.13 #1 SMP Tue May 6 02:47:45 EDT 2014 i686 i686 i386 
GNU/Linux

[root@ol6-i386 tunable]# cat /proc/self/maps
08048000-08053000 r-xp 00000000 fd:00 135174     /bin/cat
08053000-08054000 rw-p 0000a000 fd:00 135174     /bin/cat
0962e000-0964f000 rw-p 00000000 00:00 0          [heap]
b737d000-b757d000 r--p 00000000 fd:00 134061 
/usr/lib/locale/locale-archive
b757d000-b757e000 rw-p 00000000 00:00 0
b757e000-b770f000 r-xp 00000000 fd:00 2069       /lib/libc-2.12.so
b770f000-b7711000 r--p 00191000 fd:00 2069       /lib/libc-2.12.so
b7711000-b7712000 rw-p 00193000 fd:00 2069       /lib/libc-2.12.so
b7712000-b7715000 rw-p 00000000 00:00 0
b771a000-b771b000 rw-p 00000000 00:00 0
b771b000-b771c000 r-xp 00000000 00:00 0          [vdso]
b771c000-b773a000 r-xp 00000000 fd:00 2062       /lib/ld-2.12.so
b773a000-b773b000 r--p 0001d000 fd:00 2062       /lib/ld-2.12.so
b773b000-b773c000 rw-p 0001e000 fd:00 2062       /lib/ld-2.12.so
bf8b7000-bf8d8000 rw-p 00000000 00:00 0          [stack]

[root@ol6-i386 tunable]# ./max_map_count
max_map_count    0  TINFO  :  set overcommit_memory to 2
max_map_count    0  TINFO  :  set max_map_count to 64
max_map_count    1  TPASS  :  64 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 256
max_map_count    2  TPASS  :  256 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 1024
max_map_count    3  TPASS  :  1024 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 4096
max_map_count    4  TPASS  :  4096 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 16384
max_map_count    5  TPASS  :  16384 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 65536
max_map_count    6  TPASS  :  65536 map entries in total as expected.
max_map_count    0  TINFO  :  set overcommit_memory to 0
max_map_count    0  TINFO  :  set max_map_count to 65530

It's a virtual machine in VirtualBox-4.3-4.3.10_93012_el6-1.x86_64


>
> Thanks and Regards
> Diwakar Sharma
>
>
>
> -----Original Message-----
> From: Stanislav Kholmanskikh [mailto:stanislav.kholmanskikh@oracle.com]
> Sent: Monday, May 05, 2014 6:32 PM
> To: Diwakar Sharma (RBEI/ECF3); ltp-list@lists.sourceforge.net
> Subject: Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4
>
>
>
> On 05/05/2014 10:52 AM, Diwakar Sharma (RBEI/ECF3) wrote:
>> Hi,
>
> Hi!
>
>>
>> I was getting the max_map_count test failed. It looked to me failing at filter_map function. The platform I'm working on is an i686 architecture running on Virtualbox.
>> I added below additional macro condition and it's passing now. I want to understand if not including i686/386 was intentional originally for some reason? Also vdso part I added additionaly.
>>
>> #elif defined(__i686__) || defined(__i386__)
>> static int filter_map(char *line)
>> {
>>           char buf[BUFSIZ];
>>           int ret;
>>
>>           ret = sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf);
>>           if (ret != 1)
>>                   return 0;
>>
>>           return ((strcmp(buf, "[vdso]") == 0) | (strcmp(buf, "[vsyscall]") == 0));
>> }
>>
>>
>> On another similar architecture (but the actual h/w board), the same code gives messages like "4096 map entries in total, but expected 4096 entries" and reported FAIL, implying map_count and max_maps is same ( Contrary to map_count==max_maps+1 ). How do we analyze this scenario? Does this mean it is not exceeding by one for sysctl setting? How to verify that.
>>
>
> Which kernel version do you use? I want to check this test case in my
> environment.
>
> Thanks.
>
> PS: Also look at this thread
> http://sourceforge.net/p/ltp/mailman/ltp-list/thread/52009D26.4030609%40oracle.com/
>
>>
>> Thanks and Regards
>> Diwakar Sharma
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Ltp-list mailing list
>> Ltp-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ltp-list
>>

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4

[Diwakar Sharma (RBEI/ECF3)]

One more thing I want to mention here is that the platform where it is failing is intel based target, while the one where it passes is arm based target.

Thanks and Regards
Diwakar Sharma, RBEI/ECF3
Robert Bosch Engineering and Business Solutions Limited,
123, Industrial Layout, Hosur Road, Koramangala,
Bangalore - 560 095, INDIA
+91-080-6657-5459
diwakar.sharma@in.bosch.com


-----Original Message-----
From: Stanislav Kholmanskikh [mailto:stanislav.kholmanskikh@oracle.com] 
Sent: Tuesday, May 06, 2014 2:27 PM
To: Diwakar Sharma (RBEI/ECF3); ltp-list@lists.sourceforge.net
Subject: Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4



On 05/05/2014 05:06 PM, Diwakar Sharma (RBEI/ECF3) wrote:
> Hello,
>
> I am using 3.8.13.21
>
> oracle-virtualbox:/usr/lib# uname -r
> 3.8.13.21

Hmm, max_map_count passes with vanilla kernel 3.8.13 and the current LTP 
git version:

[root@ol6-i386 tunable]# uname -a
Linux ol6-i386 3.8.13 #1 SMP Tue May 6 02:47:45 EDT 2014 i686 i686 i386 
GNU/Linux

[root@ol6-i386 tunable]# cat /proc/self/maps
08048000-08053000 r-xp 00000000 fd:00 135174     /bin/cat
08053000-08054000 rw-p 0000a000 fd:00 135174     /bin/cat
0962e000-0964f000 rw-p 00000000 00:00 0          [heap]
b737d000-b757d000 r--p 00000000 fd:00 134061 
/usr/lib/locale/locale-archive
b757d000-b757e000 rw-p 00000000 00:00 0
b757e000-b770f000 r-xp 00000000 fd:00 2069       /lib/libc-2.12.so
b770f000-b7711000 r--p 00191000 fd:00 2069       /lib/libc-2.12.so
b7711000-b7712000 rw-p 00193000 fd:00 2069       /lib/libc-2.12.so
b7712000-b7715000 rw-p 00000000 00:00 0
b771a000-b771b000 rw-p 00000000 00:00 0
b771b000-b771c000 r-xp 00000000 00:00 0          [vdso]
b771c000-b773a000 r-xp 00000000 fd:00 2062       /lib/ld-2.12.so
b773a000-b773b000 r--p 0001d000 fd:00 2062       /lib/ld-2.12.so
b773b000-b773c000 rw-p 0001e000 fd:00 2062       /lib/ld-2.12.so
bf8b7000-bf8d8000 rw-p 00000000 00:00 0          [stack]

[root@ol6-i386 tunable]# ./max_map_count
max_map_count    0  TINFO  :  set overcommit_memory to 2
max_map_count    0  TINFO  :  set max_map_count to 64
max_map_count    1  TPASS  :  64 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 256
max_map_count    2  TPASS  :  256 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 1024
max_map_count    3  TPASS  :  1024 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 4096
max_map_count    4  TPASS  :  4096 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 16384
max_map_count    5  TPASS  :  16384 map entries in total as expected.
max_map_count    0  TINFO  :  set max_map_count to 65536
max_map_count    6  TPASS  :  65536 map entries in total as expected.
max_map_count    0  TINFO  :  set overcommit_memory to 0
max_map_count    0  TINFO  :  set max_map_count to 65530

It's a virtual machine in VirtualBox-4.3-4.3.10_93012_el6-1.x86_64


>
> Thanks and Regards
> Diwakar Sharma
>
>
>
> -----Original Message-----
> From: Stanislav Kholmanskikh [mailto:stanislav.kholmanskikh@oracle.com]
> Sent: Monday, May 05, 2014 6:32 PM
> To: Diwakar Sharma (RBEI/ECF3); ltp-list@lists.sourceforge.net
> Subject: Re: [LTP] - Kernel - tunable max_map_count test failure - 20140115-46-g2368cd4
>
>
>
> On 05/05/2014 10:52 AM, Diwakar Sharma (RBEI/ECF3) wrote:
>> Hi,
>
> Hi!
>
>>
>> I was getting the max_map_count test failed. It looked to me failing at filter_map function. The platform I'm working on is an i686 architecture running on Virtualbox.
>> I added below additional macro condition and it's passing now. I want to understand if not including i686/386 was intentional originally for some reason? Also vdso part I added additionaly.
>>
>> #elif defined(__i686__) || defined(__i386__)
>> static int filter_map(char *line)
>> {
>>           char buf[BUFSIZ];
>>           int ret;
>>
>>           ret = sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf);
>>           if (ret != 1)
>>                   return 0;
>>
>>           return ((strcmp(buf, "[vdso]") == 0) | (strcmp(buf, "[vsyscall]") == 0));
>> }
>>
>>
>> On another similar architecture (but the actual h/w board), the same code gives messages like "4096 map entries in total, but expected 4096 entries" and reported FAIL, implying map_count and max_maps is same ( Contrary to map_count==max_maps+1 ). How do we analyze this scenario? Does this mean it is not exceeding by one for sysctl setting? How to verify that.
>>
>
> Which kernel version do you use? I want to check this test case in my
> environment.
>
> Thanks.
>
> PS: Also look at this thread
> http://sourceforge.net/p/ltp/mailman/ltp-list/thread/52009D26.4030609%40oracle.com/
>
>>
>> Thanks and Regards
>> Diwakar Sharma
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Ltp-list mailing list
>> Ltp-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ltp-list
>>

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list