From: Hauke Mehrtens <hauke@hauke-m.de>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Cc: alex.smith@imgtec.com,
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Subject: Re: [PATCH] MIPS: vdso: flush the vdso data page to update it on all processes
Date: Sun, 21 Feb 2016 14:29:10 +0100 [thread overview]
Message-ID: <56C9BBA6.4080607@hauke-m.de> (raw)
In-Reply-To: <1456059443-13889-1-git-send-email-hauke@hauke-m.de>
On 02/21/2016 01:57 PM, Hauke Mehrtens wrote:
> Without flushing the vdso data page the vdso call is working on dated
> or unsynced data. This resulted in problems where the clock_gettime
> vdso call returned a time 6 seconds later after a 3 sounds sleep,
> while the syscall reported a time 3 sounds later like expected. This
> happened very often and I got these ping results for example:
>
> root@OpenWrt:/# ping 192.168.1.255
> PING 192.168.1.255 (192.168.1.255): 56 data bytes
> 64 bytes from 192.168.1.3: seq=0 ttl=64 time=0.688 ms
> 64 bytes from 192.168.1.3: seq=1 ttl=64 time=4294172.045 ms
> 64 bytes from 192.168.1.3: seq=2 ttl=64 time=4293968.105 ms
> 64 bytes from 192.168.1.3: seq=3 ttl=64 time=4294055.920 ms
> 64 bytes from 192.168.1.3: seq=4 ttl=64 time=4294671.913 ms
>
> The flush is now done like it is done on the arm architecture code.
>
> This was tested on a Lantiq/Intel VRX288 (MIPS BE 34Kc V5.6 CPU with
> two VPEs)
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Cc: <stable@vger.kernel.org> # v4.4+
I did some more tests and it is better now, but the problem is not
completely fixed, see this:
root@OpenWrt:/# ping 192.168.1.195
PING 192.168.1.195 (192.168.1.195): 56 data bytes
64 bytes from 192.168.1.195: seq=0 ttl=64 time=0.506 ms
64 bytes from 192.168.1.195: seq=1 ttl=64 time=4294951.724 ms
64 bytes from 192.168.1.195: seq=2 ttl=64 time=0.441 ms
64 bytes from 192.168.1.195: seq=3 ttl=64 time=0.412 ms
64 bytes from 192.168.1.195: seq=4 ttl=64 time=0.440 ms
64 bytes from 192.168.1.195: seq=5 ttl=64 time=0.435 ms
64 bytes from 192.168.1.195: seq=6 ttl=64 time=0.403 ms
64 bytes from 192.168.1.195: seq=7 ttl=64 time=0.406 ms
64 bytes from 192.168.1.195: seq=8 ttl=64 time=0.403 ms
64 bytes from 192.168.1.195: seq=9 ttl=64 time=0.406 ms
64 bytes from 192.168.1.195: seq=10 ttl=64 time=0.448 ms
64 bytes from 192.168.1.195: seq=11 ttl=64 time=0.399 ms
64 bytes from 192.168.1.195: seq=12 ttl=64 time=0.436 ms
64 bytes from 192.168.1.195: seq=13 ttl=64 time=0.438 ms
64 bytes from 192.168.1.195: seq=14 ttl=64 time=0.439 ms
Does anybody has an idea what else cloud be wrong?
Hauke
prev parent reply other threads:[~2016-02-21 13:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-21 12:57 [PATCH] MIPS: vdso: flush the vdso data page to update it on all processes Hauke Mehrtens
2016-02-21 13:18 ` Sergei Shtylyov
2016-02-21 13:29 ` Hauke Mehrtens [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C9BBA6.4080607@hauke-m.de \
--to=hauke@hauke-m.de \
--cc=alex.smith@imgtec.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=sergei.shtylyov@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.