[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.
>