[LTP] readahead02 failure on PPC

[LTP] readahead02 failure on PPC

[Kshitij Malik]

Hi,


I'm working on PowerPc based board MPC8360 and we are running 4.1.13 kernel. During our LTP run, we saw the following failure with readahead02 test.


readahead02    0  TWARN  :  readahead02.c:353: using less cache than expected


The log file is attached to this mail.


Please note that I'm running the latest LTP code and has the latest readahead02.c patch checked in yesterday.


Can you please help me in finding out the solution for this issue?


Please let me know if you need any other information.


Thanks

KK

________________________________
NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20160317/342f8372/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ltp_console_output.log
Type: application/octet-stream
Size: 3497 bytes
Desc: Ltp_console_output.log
URL: <http://lists.linux.it/pipermail/ltp/attachments/20160317/342f8372/attachment-0001.obj>

[LTP] readahead02 failure on PPC

[Kshitij Malik]

copying Jan..

________________________________
From: Kshitij Malik
Sent: Thursday, March 17, 2016 13:40
To: ltp@lists.linux.it
Subject: readahead02 failure on PPC


Hi,


I'm working on PowerPc based board MPC8360 and we are running 4.1.13 kernel. During our LTP run, we saw the following failure with readahead02 test.


readahead02    0  TWARN  :  readahead02.c:353: using less cache than expected


The log file is attached to this mail.


Please note that I'm running the latest LTP code and has the latest readahead02.c patch checked in yesterday.


Can you please help me in finding out the solution for this issue?


Please let me know if you need any other information.


Thanks

KK

________________________________
NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20160317/83320c12/attachment.html>

[LTP] readahead02 failure on PPC

[Jan Stancek]

----- Original Message -----
> From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> To: ltp@lists.linux.it
> Sent: Thursday, 17 March, 2016 6:40:58 PM
> Subject: [LTP] readahead02 failure on PPC
> 
> 
> 
> Hi,

Hi,

we prefer plain text over html emails on this list.

> 
> I'm working on PowerPc based board MPC8360 and we are running 4.1.13 kernel.

and from previous issue you reported, I recall this is 32bit environment.

> During our LTP run, we saw the following failure with readahead02 test.
> 
> readahead02 0 TWARN : readahead02.c:353: using less cache than expected
> The log file is attached to this mail.

readahead has no effect. It's supposed to read file into cache, so we
expect change in used cache and that subsequent reads will be faster
(because data is already in memory).

> 
> Please note that I'm running the latest LTP code and has the latest
> readahead02.c patch checked in yesterday.
> Can you please help me in finding out the solution for this issue?

Just to confirm, this is not an issue with passing 64bit parameter
in syscall(), can you try running it with this change and send us output?

diff --git a/testcases/kernel/syscalls/readahead/readahead02.c b/testcases/kernel/syscalls/readahead/readahead02.c
index 7dc308c03e5d..0b42542d0d13 100644
--- a/testcases/kernel/syscalls/readahead/readahead02.c
+++ b/testcases/kernel/syscalls/readahead/readahead02.c
@@ -236,7 +236,7 @@ static void read_testfile(int do_readahead, const char *fname, size_t fsize,

        if (do_readahead) {
                for (i = 0; i < fsize; i += readahead_size) {
-                       TEST(ltp_syscall(__NR_readahead, fd,
+                       TEST(readahead(fd,
                                (off64_t) i, readahead_size));
                        if (TEST_RETURN != 0)
                                break;

> Please let me know if you need any other information.

If that makes no difference, "strace -T" could tell us how much time
is kernel spending in this syscall.

There was an issue with readahead on ppc a while ago, where readahead
was effectively ignored on memory-less nodes, but you should have that
patch already:
  commit 6d2be915e589b58cb11418cbe1f22ff90732b6ac
  Author: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
  Date:   Thu Apr 3 14:48:23 2014 -0700
    mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit readahead pages

Regards,
Jan

[LTP] readahead02 failure on PPC

[Kshitij Malik]

Hi Jan,

Sorry for the html mails. I will move to the desktop outlook tomorrow to avoid this.

You were right, the issue is because of the 64 bit data being passed in syscall. With your patch, I don't see the issue anymore. I ran the test again and again (7-8 times) and it is not failing anymore.

we are a 32 bit ppc system and do we really need this test. Can this test be modified such that syscall is called for PPC 64 architecture and readahead for 32 bit?

Thanks
KK
________________________________________
From: Jan Stancek <jstancek@redhat.com>
Sent: Thursday, March 17, 2016 17:17
To: Kshitij Malik
Cc: ltp@lists.linux.it
Subject: Re: [LTP] readahead02 failure on PPC

----- Original Message -----
> From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> To: ltp@lists.linux.it
> Sent: Thursday, 17 March, 2016 6:40:58 PM
> Subject: [LTP] readahead02 failure on PPC
>
>
>
> Hi,

Hi,

we prefer plain text over html emails on this list.

>
> I'm working on PowerPc based board MPC8360 and we are running 4.1.13 kernel.

and from previous issue you reported, I recall this is 32bit environment.

> During our LTP run, we saw the following failure with readahead02 test.
>
> readahead02 0 TWARN : readahead02.c:353: using less cache than expected
> The log file is attached to this mail.

readahead has no effect. It's supposed to read file into cache, so we
expect change in used cache and that subsequent reads will be faster
(because data is already in memory).

>
> Please note that I'm running the latest LTP code and has the latest
> readahead02.c patch checked in yesterday.
> Can you please help me in finding out the solution for this issue?

Just to confirm, this is not an issue with passing 64bit parameter
in syscall(), can you try running it with this change and send us output?

diff --git a/testcases/kernel/syscalls/readahead/readahead02.c b/testcases/kernel/syscalls/readahead/readahead02.c
index 7dc308c03e5d..0b42542d0d13 100644
--- a/testcases/kernel/syscalls/readahead/readahead02.c
+++ b/testcases/kernel/syscalls/readahead/readahead02.c
@@ -236,7 +236,7 @@ static void read_testfile(int do_readahead, const char *fname, size_t fsize,

        if (do_readahead) {
                for (i = 0; i < fsize; i += readahead_size) {
-                       TEST(ltp_syscall(__NR_readahead, fd,
+                       TEST(readahead(fd,
                                (off64_t) i, readahead_size));
                        if (TEST_RETURN != 0)
                                break;

> Please let me know if you need any other information.

If that makes no difference, "strace -T" could tell us how much time
is kernel spending in this syscall.

There was an issue with readahead on ppc a while ago, where readahead
was effectively ignored on memory-less nodes, but you should have that
patch already:
  commit 6d2be915e589b58cb11418cbe1f22ff90732b6ac
  Author: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
  Date:   Thu Apr 3 14:48:23 2014 -0700
    mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit readahead pages

Regards,
Jan
________________________________
NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[LTP] readahead02 failure on PPC

[Jan Stancek]

----- Original Message -----
> From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 17 March, 2016 11:03:23 PM
> Subject: Re: [LTP] readahead02 failure on PPC
> 
> Hi Jan,
> 
> Sorry for the html mails. I will move to the desktop outlook tomorrow to
> avoid this.
> 
> You were right, the issue is because of the 64 bit data being passed in
> syscall. With your patch, I don't see the issue anymore. I ran the test
> again and again (7-8 times) and it is not failing anymore.
> 
> we are a 32 bit ppc system and do we really need this test. Can this test be
> modified such that syscall is called for PPC 64 architecture and readahead
> for 32 bit?

I think best would be to add configure check and use readahead() glibc
function whenever possible.

I'm adding CC on Julio, he reported something similar couple days ago,
I suspect it's the same problem. Julio, can you confirm? (see patch below)

Regards,
Jan

> 
> Thanks
> KK
> ________________________________________
> From: Jan Stancek <jstancek@redhat.com>
> Sent: Thursday, March 17, 2016 17:17
> To: Kshitij Malik
> Cc: ltp@lists.linux.it
> Subject: Re: [LTP] readahead02 failure on PPC
> 
> ----- Original Message -----
> > From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> > To: ltp@lists.linux.it
> > Sent: Thursday, 17 March, 2016 6:40:58 PM
> > Subject: [LTP] readahead02 failure on PPC
> >
> >
> >
> > Hi,
> 
> Hi,
> 
> we prefer plain text over html emails on this list.
> 
> >
> > I'm working on PowerPc based board MPC8360 and we are running 4.1.13
> > kernel.
> 
> and from previous issue you reported, I recall this is 32bit environment.
> 
> > During our LTP run, we saw the following failure with readahead02 test.
> >
> > readahead02 0 TWARN : readahead02.c:353: using less cache than expected
> > The log file is attached to this mail.
> 
> readahead has no effect. It's supposed to read file into cache, so we
> expect change in used cache and that subsequent reads will be faster
> (because data is already in memory).
> 
> >
> > Please note that I'm running the latest LTP code and has the latest
> > readahead02.c patch checked in yesterday.
> > Can you please help me in finding out the solution for this issue?
> 
> Just to confirm, this is not an issue with passing 64bit parameter
> in syscall(), can you try running it with this change and send us output?
> 
> diff --git a/testcases/kernel/syscalls/readahead/readahead02.c
> b/testcases/kernel/syscalls/readahead/readahead02.c
> index 7dc308c03e5d..0b42542d0d13 100644
> --- a/testcases/kernel/syscalls/readahead/readahead02.c
> +++ b/testcases/kernel/syscalls/readahead/readahead02.c
> @@ -236,7 +236,7 @@ static void read_testfile(int do_readahead, const char
> *fname, size_t fsize,
> 
>         if (do_readahead) {
>                 for (i = 0; i < fsize; i += readahead_size) {
> -                       TEST(ltp_syscall(__NR_readahead, fd,
> +                       TEST(readahead(fd,
>                                 (off64_t) i, readahead_size));
>                         if (TEST_RETURN != 0)
>                                 break;
> 
> > Please let me know if you need any other information.
> 
> If that makes no difference, "strace -T" could tell us how much time
> is kernel spending in this syscall.
> 
> There was an issue with readahead on ppc a while ago, where readahead
> was effectively ignored on memory-less nodes, but you should have that
> patch already:
>   commit 6d2be915e589b58cb11418cbe1f22ff90732b6ac
>   Author: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>   Date:   Thu Apr 3 14:48:23 2014 -0700
>     mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit
>     readahead pages
> 
> Regards,
> Jan
> ________________________________
> NOTE: This e-mail (including any attachments) is for the sole use of the
> intended recipient(s) and may contain information that is confidential
> and/or protected by legal privilege. Any unauthorized review, use, copy,
> disclosure or distribution of this e-mail is strictly prohibited. If you are
> not the intended recipient, please notify Mitel immediately and destroy all
> copies of this e-mail. Mitel does not accept any liability for breach of
> security, error or virus that may result from the transmission of this
> message.
> 

[LTP] readahead02 failure on PPC

[Kshitij Malik]

Hi Jan,

Did you get any confirmation from Julio?

Since you suggested to call readahead() glibc function as a fix, will that be again going under #ifdef __powerpc__ flag?

Thanks
KK
________________________________________
From: Jan Stancek <jstancek@redhat.com>
Sent: Friday, March 18, 2016 04:42
To: Kshitij Malik
Cc: ltp@lists.linux.it; Julio Cruz
Subject: Re: [LTP] readahead02 failure on PPC

----- Original Message -----
> From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 17 March, 2016 11:03:23 PM
> Subject: Re: [LTP] readahead02 failure on PPC
>
> Hi Jan,
>
> Sorry for the html mails. I will move to the desktop outlook tomorrow to
> avoid this.
>
> You were right, the issue is because of the 64 bit data being passed in
> syscall. With your patch, I don't see the issue anymore. I ran the test
> again and again (7-8 times) and it is not failing anymore.
>
> we are a 32 bit ppc system and do we really need this test. Can this test be
> modified such that syscall is called for PPC 64 architecture and readahead
> for 32 bit?

I think best would be to add configure check and use readahead() glibc
function whenever possible.

I'm adding CC on Julio, he reported something similar couple days ago,
I suspect it's the same problem. Julio, can you confirm? (see patch below)

Regards,
Jan

>
> Thanks
> KK
> ________________________________________
> From: Jan Stancek <jstancek@redhat.com>
> Sent: Thursday, March 17, 2016 17:17
> To: Kshitij Malik
> Cc: ltp@lists.linux.it
> Subject: Re: [LTP] readahead02 failure on PPC
>
> ----- Original Message -----
> > From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> > To: ltp@lists.linux.it
> > Sent: Thursday, 17 March, 2016 6:40:58 PM
> > Subject: [LTP] readahead02 failure on PPC
> >
> >
> >
> > Hi,
>
> Hi,
>
> we prefer plain text over html emails on this list.
>
> >
> > I'm working on PowerPc based board MPC8360 and we are running 4.1.13
> > kernel.
>
> and from previous issue you reported, I recall this is 32bit environment.
>
> > During our LTP run, we saw the following failure with readahead02 test.
> >
> > readahead02 0 TWARN : readahead02.c:353: using less cache than expected
> > The log file is attached to this mail.
>
> readahead has no effect. It's supposed to read file into cache, so we
> expect change in used cache and that subsequent reads will be faster
> (because data is already in memory).
>
> >
> > Please note that I'm running the latest LTP code and has the latest
> > readahead02.c patch checked in yesterday.
> > Can you please help me in finding out the solution for this issue?
>
> Just to confirm, this is not an issue with passing 64bit parameter
> in syscall(), can you try running it with this change and send us output?
>
> diff --git a/testcases/kernel/syscalls/readahead/readahead02.c
> b/testcases/kernel/syscalls/readahead/readahead02.c
> index 7dc308c03e5d..0b42542d0d13 100644
> --- a/testcases/kernel/syscalls/readahead/readahead02.c
> +++ b/testcases/kernel/syscalls/readahead/readahead02.c
> @@ -236,7 +236,7 @@ static void read_testfile(int do_readahead, const char
> *fname, size_t fsize,
>
>         if (do_readahead) {
>                 for (i = 0; i < fsize; i += readahead_size) {
> -                       TEST(ltp_syscall(__NR_readahead, fd,
> +                       TEST(readahead(fd,
>                                 (off64_t) i, readahead_size));
>                         if (TEST_RETURN != 0)
>                                 break;
>
> > Please let me know if you need any other information.
>
> If that makes no difference, "strace -T" could tell us how much time
> is kernel spending in this syscall.
>
> There was an issue with readahead on ppc a while ago, where readahead
> was effectively ignored on memory-less nodes, but you should have that
> patch already:
>   commit 6d2be915e589b58cb11418cbe1f22ff90732b6ac
>   Author: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>   Date:   Thu Apr 3 14:48:23 2014 -0700
>     mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit
>     readahead pages
>
> Regards,
> Jan
> ________________________________
> NOTE: This e-mail (including any attachments) is for the sole use of the
> intended recipient(s) and may contain information that is confidential
> and/or protected by legal privilege. Any unauthorized review, use, copy,
> disclosure or distribution of this e-mail is strictly prohibited. If you are
> not the intended recipient, please notify Mitel immediately and destroy all
> copies of this e-mail. Mitel does not accept any liability for breach of
> security, error or virus that may result from the transmission of this
> message.
>
________________________________
NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[LTP] readahead02 failure on PPC

[Jan Stancek]

----- Original Message -----
> From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it, "Julio Cruz" <jcsistemas2001@gmail.com>
> Sent: Monday, 21 March, 2016 7:38:07 PM
> Subject: Re: [LTP] readahead02 failure on PPC
> 
> Hi Jan,
> 
> Did you get any confirmation from Julio?

Not yet.

> 
> Since you suggested to call readahead() glibc function as a fix, will that be
> again going under #ifdef __powerpc__ flag?

No, I didn't mean this to be arch-specific.

> 
> Thanks
> KK
> ________________________________________
> From: Jan Stancek <jstancek@redhat.com>
> Sent: Friday, March 18, 2016 04:42
> To: Kshitij Malik
> Cc: ltp@lists.linux.it; Julio Cruz
> Subject: Re: [LTP] readahead02 failure on PPC
> 
> ----- Original Message -----
> > From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> > To: "Jan Stancek" <jstancek@redhat.com>
> > Cc: ltp@lists.linux.it
> > Sent: Thursday, 17 March, 2016 11:03:23 PM
> > Subject: Re: [LTP] readahead02 failure on PPC
> >
> > Hi Jan,
> >
> > Sorry for the html mails. I will move to the desktop outlook tomorrow to
> > avoid this.
> >
> > You were right, the issue is because of the 64 bit data being passed in
> > syscall. With your patch, I don't see the issue anymore. I ran the test
> > again and again (7-8 times) and it is not failing anymore.
> >
> > we are a 32 bit ppc system and do we really need this test. Can this test
> > be
> > modified such that syscall is called for PPC 64 architecture and readahead
> > for 32 bit?
> 
> I think best would be to add configure check and use readahead() glibc
> function whenever possible.
> 
> I'm adding CC on Julio, he reported something similar couple days ago,
> I suspect it's the same problem. Julio, can you confirm? (see patch below)
> 
> Regards,
> Jan
> 
> >
> > Thanks
> > KK
> > ________________________________________
> > From: Jan Stancek <jstancek@redhat.com>
> > Sent: Thursday, March 17, 2016 17:17
> > To: Kshitij Malik
> > Cc: ltp@lists.linux.it
> > Subject: Re: [LTP] readahead02 failure on PPC
> >
> > ----- Original Message -----
> > > From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> > > To: ltp@lists.linux.it
> > > Sent: Thursday, 17 March, 2016 6:40:58 PM
> > > Subject: [LTP] readahead02 failure on PPC
> > >
> > >
> > >
> > > Hi,
> >
> > Hi,
> >
> > we prefer plain text over html emails on this list.
> >
> > >
> > > I'm working on PowerPc based board MPC8360 and we are running 4.1.13
> > > kernel.
> >
> > and from previous issue you reported, I recall this is 32bit environment.
> >
> > > During our LTP run, we saw the following failure with readahead02 test.
> > >
> > > readahead02 0 TWARN : readahead02.c:353: using less cache than expected
> > > The log file is attached to this mail.
> >
> > readahead has no effect. It's supposed to read file into cache, so we
> > expect change in used cache and that subsequent reads will be faster
> > (because data is already in memory).
> >
> > >
> > > Please note that I'm running the latest LTP code and has the latest
> > > readahead02.c patch checked in yesterday.
> > > Can you please help me in finding out the solution for this issue?
> >
> > Just to confirm, this is not an issue with passing 64bit parameter
> > in syscall(), can you try running it with this change and send us output?
> >
> > diff --git a/testcases/kernel/syscalls/readahead/readahead02.c
> > b/testcases/kernel/syscalls/readahead/readahead02.c
> > index 7dc308c03e5d..0b42542d0d13 100644
> > --- a/testcases/kernel/syscalls/readahead/readahead02.c
> > +++ b/testcases/kernel/syscalls/readahead/readahead02.c
> > @@ -236,7 +236,7 @@ static void read_testfile(int do_readahead, const char
> > *fname, size_t fsize,
> >
> >         if (do_readahead) {
> >                 for (i = 0; i < fsize; i += readahead_size) {
> > -                       TEST(ltp_syscall(__NR_readahead, fd,
> > +                       TEST(readahead(fd,
> >                                 (off64_t) i, readahead_size));
> >                         if (TEST_RETURN != 0)
> >                                 break;
> >
> > > Please let me know if you need any other information.
> >
> > If that makes no difference, "strace -T" could tell us how much time
> > is kernel spending in this syscall.
> >
> > There was an issue with readahead on ppc a while ago, where readahead
> > was effectively ignored on memory-less nodes, but you should have that
> > patch already:
> >   commit 6d2be915e589b58cb11418cbe1f22ff90732b6ac
> >   Author: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> >   Date:   Thu Apr 3 14:48:23 2014 -0700
> >     mm/readahead.c: fix readahead failure for memoryless NUMA nodes and
> >     limit
> >     readahead pages
> >
> > Regards,
> > Jan
> > ________________________________
> > NOTE: This e-mail (including any attachments) is for the sole use of the
> > intended recipient(s) and may contain information that is confidential
> > and/or protected by legal privilege. Any unauthorized review, use, copy,
> > disclosure or distribution of this e-mail is strictly prohibited. If you
> > are
> > not the intended recipient, please notify Mitel immediately and destroy all
> > copies of this e-mail. Mitel does not accept any liability for breach of
> > security, error or virus that may result from the transmission of this
> > message.
> >
> ________________________________
> NOTE: This e-mail (including any attachments) is for the sole use of the
> intended recipient(s) and may contain information that is confidential
> and/or protected by legal privilege. Any unauthorized review, use, copy,
> disclosure or distribution of this e-mail is strictly prohibited. If you are
> not the intended recipient, please notify Mitel immediately and destroy all
> copies of this e-mail. Mitel does not accept any liability for breach of
> security, error or virus that may result from the transmission of this
> message.
> 

[LTP] readahead02 failure on PPC

[Julio Cruz Barroso]

Hi Jan, Kshitij,

I just saw this email! 

I will review the issue because I cannot remember the result details and let you know tomorrow (CST).

I expect also to upload the others patchs reviewed.

Regards

Julio


> On Mar 22, 2016, at 5:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> 
> Kshitij

[LTP] readahead02 failure on PPC

[Julio Cruz Barroso]

Hi Jan, Kshitij,

Checking my logs (imx6 32bits based platform) the error is similar [1]:

readahead02 0 TWARN : readahead02.c:324: using less cache than expected

However, the results were not consistent, because, once time PASS and another FAIL (with previous TWARN).

Another thing different was (in my case):

readahead02 3 TCONF : readahead02.c:309: Your system doesn't have /proc/pid/io, unable to determine read bytes during test

This last one, is the part 1 of the test case (read bytes during test). The part 2 (verify the cache) is the same TWARN.

At the end, I skipped this test case because the results were not consistent and need further analysis.

Regards,
Julio


[1] logs for imx6: https://justpaste.it/s4zk

-----Original Message-----
From: ltp [mailto:ltp-bounces+julio.cruz=smartmatic.com@lists.linux.it] On Behalf Of Julio Cruz Barroso
Sent: Tuesday, March 22, 2016 11:19 PM
To: Jan Stancek
Cc: Julio Cruz; Kshitij Malik; ltp@lists.linux.it
Subject: Re: [LTP] readahead02 failure on PPC

Hi Jan, Kshitij,

I just saw this email! 

I will review the issue because I cannot remember the result details and let you know tomorrow (CST).

I expect also to upload the others patchs reviewed.

Regards

Julio


> On Mar 22, 2016, at 5:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> 
> Kshitij

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] readahead02 failure on PPC

[Kshitij Malik]

Hi Julio,

Thank you for the update.

I was also getting the /proc/pid/io error to start with and I fixed it by enabling kernel configurations CONFIG_TASKSTATS, CONFIG_TASK_IO_ACCOUNTING and other related configs.

These configs creates the io directory for a thread in proc.

Jan,

Do you think your fix can be used as an official patch?

Thanks
KK

On Mar 22, 2016 22:39, Julio Cruz Barroso <julio.cruz@smartmatic.com> wrote:
>
> Hi Jan, Kshitij,
>
> Checking my logs (imx6 32bits based platform) the error is similar [1]:
>
> readahead02 0 TWARN : readahead02.c:324: using less cache than expected
>
> However, the results were not consistent, because, once time PASS and another FAIL (with previous TWARN).
>
> Another thing different was (in my case):
>
> readahead02 3 TCONF : readahead02.c:309: Your system doesn't have /proc/pid/io, unable to determine read bytes during test
>
> This last one, is the part 1 of the test case (read bytes during test). The part 2 (verify the cache) is the same TWARN.
>
> At the end, I skipped this test case because the results were not consistent and need further analysis.
>
> Regards,
> Julio
>
>
> [1] logs for imx6: https://justpaste.it/s4zk
>
> -----Original Message-----
> From: ltp [mailto:ltp-bounces+julio.cruz=smartmatic.com@lists.linux.it] On Behalf Of Julio Cruz Barroso
> Sent: Tuesday, March 22, 2016 11:19 PM
> To: Jan Stancek
> Cc: Julio Cruz; Kshitij Malik; ltp@lists.linux.it
> Subject: Re: [LTP] readahead02 failure on PPC
>
> Hi Jan, Kshitij,
>
> I just saw this email!
>
> I will review the issue because I cannot remember the result details and let you know tomorrow (CST).
>
> I expect also to upload the others patchs reviewed.
>
> Regards
>
> Julio
>
>
> > On Mar 22, 2016, at 5:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> >
> > Kshitij
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
________________________________
NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.

[LTP] readahead02 failure on PPC

[Julio Cruz Barroso]

Hi again,

Additionally, to previous comments, I try the patch in a 32bits system (with Kernel 3.14) and the TWARN is gone. 

I perform the test 10 times in two boards: 1) 32 bits with one core and 512MB RAM and 2) 32 bits with two cores and same RAM:

- With patch: 5 times show PASS in both boards
- Without patch: 5 times show FAIL in both boards

This time, I don’t get inconsistent results. 

Regards

Julio

> -----Original Message-----
> From: Kshitij Malik [mailto:Kshitij.Malik@mitel.com]
> Sent: Wednesday, March 23, 2016 10:55 AM
> To: Julio Cruz Barroso
> Cc: Jan Stancek; ltp@lists.linux.it
> Subject: RE: [LTP] readahead02 failure on PPC
> 
> Hi Julio,
> 
> Thank you for the update.
> 
> I was also getting the /proc/pid/io error to start with and I fixed it by
> enabling kernel configurations CONFIG_TASKSTATS,
> CONFIG_TASK_IO_ACCOUNTING and other related configs.
> 
> These configs creates the io directory for a thread in proc.
> 
> Jan,
> 
> Do you think your fix can be used as an official patch?
> 
> Thanks
> KK
> 
> On Mar 22, 2016 22:39, Julio Cruz Barroso <julio.cruz@smartmatic.com>
> wrote:
> >
> > Hi Jan, Kshitij,
> >
> > Checking my logs (imx6 32bits based platform) the error is similar [1]:
> >
> > readahead02 0 TWARN : readahead02.c:324: using less cache than
> expected
> >
> > However, the results were not consistent, because, once time PASS and
> another FAIL (with previous TWARN).
> >
> > Another thing different was (in my case):
> >
> > readahead02 3 TCONF : readahead02.c:309: Your system doesn't have
> /proc/pid/io, unable to determine read bytes during test
> >
> > This last one, is the part 1 of the test case (read bytes during test). The part
> 2 (verify the cache) is the same TWARN.
> >
> > At the end, I skipped this test case because the results were not consistent
> and need further analysis.
> >
> > Regards,
> > Julio
> >
> >
> > [1] logs for imx6: https://justpaste.it/s4zk
> >
> > -----Original Message-----
> > From: ltp [mailto:ltp-bounces+julio.cruz=smartmatic.com@lists.linux.it] On
> Behalf Of Julio Cruz Barroso
> > Sent: Tuesday, March 22, 2016 11:19 PM
> > To: Jan Stancek
> > Cc: Julio Cruz; Kshitij Malik; ltp@lists.linux.it
> > Subject: Re: [LTP] readahead02 failure on PPC
> >
> > Hi Jan, Kshitij,
> >
> > I just saw this email!
> >
> > I will review the issue because I cannot remember the result details and let
> you know tomorrow (CST).
> >
> > I expect also to upload the others patchs reviewed.
> >
> > Regards
> >
> > Julio
> >
> >
> > > On Mar 22, 2016, at 5:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> > >
> > > Kshitij
> >
> > --
> > Mailing list info: https://lists.linux.it/listinfo/ltp
> ________________________________
> NOTE: This e-mail (including any attachments) is for the sole use of the
> intended recipient(s) and may contain information that is confidential and/or
> protected by legal privilege. Any unauthorized review, use, copy, disclosure
> or distribution of this e-mail is strictly prohibited. If you are not the intended
> recipient, please notify Mitel immediately and destroy all copies of this e-
> mail. Mitel does not accept any liability for breach of security, error or virus
> that may result from the transmission of this message.

[LTP] readahead02 failure on PPC

[Kshitij Malik]

Thank you Julio for the update.

Jan,

Can we take the changes shared by you as an official fix?

Thanks
KK
________________________________________
From: Julio Cruz Barroso <julio.cruz@smartmatic.com>
Sent: Wednesday, March 23, 2016 01:46
To: Kshitij Malik
Cc: Jan Stancek; ltp@lists.linux.it
Subject: RE: [LTP] readahead02 failure on PPC

Hi again,

Additionally, to previous comments, I try the patch in a 32bits system (with Kernel 3.14) and the TWARN is gone.

I perform the test 10 times in two boards: 1) 32 bits with one core and 512MB RAM and 2) 32 bits with two cores and same RAM:

- With patch: 5 times show PASS in both boards
- Without patch: 5 times show FAIL in both boards

This time, I don’t get inconsistent results.

Regards

Julio

> -----Original Message-----
> From: Kshitij Malik [mailto:Kshitij.Malik@mitel.com]
> Sent: Wednesday, March 23, 2016 10:55 AM
> To: Julio Cruz Barroso
> Cc: Jan Stancek; ltp@lists.linux.it
> Subject: RE: [LTP] readahead02 failure on PPC
>
> Hi Julio,
>
> Thank you for the update.
>
> I was also getting the /proc/pid/io error to start with and I fixed it by
> enabling kernel configurations CONFIG_TASKSTATS,
> CONFIG_TASK_IO_ACCOUNTING and other related configs.
>
> These configs creates the io directory for a thread in proc.
>
> Jan,
>
> Do you think your fix can be used as an official patch?
>
> Thanks
> KK
>
> On Mar 22, 2016 22:39, Julio Cruz Barroso <julio.cruz@smartmatic.com>
> wrote:
> >
> > Hi Jan, Kshitij,
> >
> > Checking my logs (imx6 32bits based platform) the error is similar [1]:
> >
> > readahead02 0 TWARN : readahead02.c:324: using less cache than
> expected
> >
> > However, the results were not consistent, because, once time PASS and
> another FAIL (with previous TWARN).
> >
> > Another thing different was (in my case):
> >
> > readahead02 3 TCONF : readahead02.c:309: Your system doesn't have
> /proc/pid/io, unable to determine read bytes during test
> >
> > This last one, is the part 1 of the test case (read bytes during test). The part
> 2 (verify the cache) is the same TWARN.
> >
> > At the end, I skipped this test case because the results were not consistent
> and need further analysis.
> >
> > Regards,
> > Julio
> >
> >
> > [1] logs for imx6: https://justpaste.it/s4zk
> >
> > -----Original Message-----
> > From: ltp [mailto:ltp-bounces+julio.cruz=smartmatic.com@lists.linux.it] On
> Behalf Of Julio Cruz Barroso
> > Sent: Tuesday, March 22, 2016 11:19 PM
> > To: Jan Stancek
> > Cc: Julio Cruz; Kshitij Malik; ltp@lists.linux.it
> > Subject: Re: [LTP] readahead02 failure on PPC
> >
> > Hi Jan, Kshitij,
> >
> > I just saw this email!
> >
> > I will review the issue because I cannot remember the result details and let
> you know tomorrow (CST).
> >
> > I expect also to upload the others patchs reviewed.
> >
> > Regards
> >
> > Julio
> >
> >
> > > On Mar 22, 2016, at 5:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> > >
> > > Kshitij
> >
> > --
> > Mailing list info: https://lists.linux.it/listinfo/ltp
> ________________________________
> NOTE: This e-mail (including any attachments) is for the sole use of the
> intended recipient(s) and may contain information that is confidential and/or
> protected by legal privilege. Any unauthorized review, use, copy, disclosure
> or distribution of this e-mail is strictly prohibited. If you are not the intended
> recipient, please notify Mitel immediately and destroy all copies of this e-
> mail. Mitel does not accept any liability for breach of security, error or virus
> that may result from the transmission of this message.

[LTP] readahead02 failure on PPC

[Jan Stancek]

----- Original Message -----
> From: "Kshitij Malik" <Kshitij.Malik@mitel.com>
> To: "Julio Cruz Barroso" <julio.cruz@smartmatic.com>, "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp@lists.linux.it
> Sent: Thursday, 24 March, 2016 3:40:21 PM
> Subject: Re: [LTP] readahead02 failure on PPC
> 
> Thank you Julio for the update.
> 
> Jan,
> 
> Can we take the changes shared by you as an official fix?

I'm on the fence whether we should also add configure check for it.
Wrapper is in glibc since 2.3, which is quite old. Let's try posting
it as is and see if anyone objects.

Regards,
Jan

> 
> Thanks
> KK
> ________________________________________
> From: Julio Cruz Barroso <julio.cruz@smartmatic.com>
> Sent: Wednesday, March 23, 2016 01:46
> To: Kshitij Malik
> Cc: Jan Stancek; ltp@lists.linux.it
> Subject: RE: [LTP] readahead02 failure on PPC
> 
> Hi again,
> 
> Additionally, to previous comments, I try the patch in a 32bits system (with
> Kernel 3.14) and the TWARN is gone.
> 
> I perform the test 10 times in two boards: 1) 32 bits with one core and 512MB
> RAM and 2) 32 bits with two cores and same RAM:
> 
> - With patch: 5 times show PASS in both boards
> - Without patch: 5 times show FAIL in both boards
> 
> This time, I don’t get inconsistent results.
> 
> Regards
> 
> Julio
> 
> > -----Original Message-----
> > From: Kshitij Malik [mailto:Kshitij.Malik@mitel.com]
> > Sent: Wednesday, March 23, 2016 10:55 AM
> > To: Julio Cruz Barroso
> > Cc: Jan Stancek; ltp@lists.linux.it
> > Subject: RE: [LTP] readahead02 failure on PPC
> >
> > Hi Julio,
> >
> > Thank you for the update.
> >
> > I was also getting the /proc/pid/io error to start with and I fixed it by
> > enabling kernel configurations CONFIG_TASKSTATS,
> > CONFIG_TASK_IO_ACCOUNTING and other related configs.
> >
> > These configs creates the io directory for a thread in proc.
> >
> > Jan,
> >
> > Do you think your fix can be used as an official patch?
> >
> > Thanks
> > KK
> >
> > On Mar 22, 2016 22:39, Julio Cruz Barroso <julio.cruz@smartmatic.com>
> > wrote:
> > >
> > > Hi Jan, Kshitij,
> > >
> > > Checking my logs (imx6 32bits based platform) the error is similar [1]:
> > >
> > > readahead02 0 TWARN : readahead02.c:324: using less cache than
> > expected
> > >
> > > However, the results were not consistent, because, once time PASS and
> > another FAIL (with previous TWARN).
> > >
> > > Another thing different was (in my case):
> > >
> > > readahead02 3 TCONF : readahead02.c:309: Your system doesn't have
> > /proc/pid/io, unable to determine read bytes during test
> > >
> > > This last one, is the part 1 of the test case (read bytes during test).
> > > The part
> > 2 (verify the cache) is the same TWARN.
> > >
> > > At the end, I skipped this test case because the results were not
> > > consistent
> > and need further analysis.
> > >
> > > Regards,
> > > Julio
> > >
> > >
> > > [1] logs for imx6: https://justpaste.it/s4zk
> > >
> > > -----Original Message-----
> > > From: ltp [mailto:ltp-bounces+julio.cruz=smartmatic.com@lists.linux.it]
> > > On
> > Behalf Of Julio Cruz Barroso
> > > Sent: Tuesday, March 22, 2016 11:19 PM
> > > To: Jan Stancek
> > > Cc: Julio Cruz; Kshitij Malik; ltp@lists.linux.it
> > > Subject: Re: [LTP] readahead02 failure on PPC
> > >
> > > Hi Jan, Kshitij,
> > >
> > > I just saw this email!
> > >
> > > I will review the issue because I cannot remember the result details and
> > > let
> > you know tomorrow (CST).
> > >
> > > I expect also to upload the others patchs reviewed.
> > >
> > > Regards
> > >
> > > Julio
> > >
> > >
> > > > On Mar 22, 2016, at 5:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> > > >
> > > > Kshitij
> > >
> > > --
> > > Mailing list info: https://lists.linux.it/listinfo/ltp
> > ________________________________
> > NOTE: This e-mail (including any attachments) is for the sole use of the
> > intended recipient(s) and may contain information that is confidential
> > and/or
> > protected by legal privilege. Any unauthorized review, use, copy,
> > disclosure
> > or distribution of this e-mail is strictly prohibited. If you are not the
> > intended
> > recipient, please notify Mitel immediately and destroy all copies of this
> > e-
> > mail. Mitel does not accept any liability for breach of security, error or
> > virus
> > that may result from the transmission of this message.
>