[LTP] readahead02 failure on PPC

Kshitij Malik Kshitij.Malik@mitel.com
Thu Mar 17 23:03:23 CET 2016


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.


More information about the ltp mailing list