Date: Mon, 14 May 2012 13:37:44 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Fredrik =?ISO-8859-1?Q?Sik=E9n?= <fredrik.siken@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: 13x longer execution times before remount Message-ID: <1337024264.1503.73.camel@revolution.hippie.lan> In-Reply-To: <CAGh%2B35MFtuDFjMkkHV%2B=X4g4uWmkG0AyJxdutFMwxfve-pUwqg@mail.gmail.com> References: <CAGh%2B35MFtuDFjMkkHV%2B=X4g4uWmkG0AyJxdutFMwxfve-pUwqg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2012-05-14 at 21:23 +0200, Fredrik Sikén wrote:
> Hi,
>
> I've an 8.2-Release running on an ARM with poor execution performance
> before a remount is performed.
>
> The scenario is as follows
>
> 0) I mount an UFS SSD disk
> # mount -o noclusterr -o noclusterw /dev/ad0s1 /mnt/
>
> 1) I copy an executable to an UFS mounted SSD disk and measure its
> time of execution from start to stop
>
> 2) I remount the system (umount/mount)
>
> 3) I perform the same steps as in 1) but now with a performance increase of 13x
>
> Other tests performed:
> - Tested on a UFS USB stick with the same behaviour
> - Tested to write to an NFS mounted disk and this gives the expected
> behaviour - the same time before and after a remount.
> - Running the same version on a x86 gives the expected behaviour - the
> same time before and after a remount.
>
> Results after file is copied but before a remount
> # time ./test 10000 1000000
> size = 10000, no = 1000000
> 133.000u 0.000s 2:13.53 99.8% 3282+18575k 0+0io 0pf+0w
>
> Results after a remount
> # time ./test 10000 1000000
> size = 10000, no = 1000000
> 7.000u 0.000s 0:07.82 99.8% 3286+18595k 0+0io 0pf+0w
>
> The test application source looks like this
> #include <string.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> int main(int argc, char **argv) {
>
> int size = atoi(argv[1]);
> int no = atoi(argv[2]);
> printf("size = %d, no = %d\n", size, no);
>
> {
> int i;
>
> for(i = 0 ; i<no ; i++) {
> char *p = malloc(size);
> memset(p, 0, size);
> free(p);
> }
> }
> }
>
> Thanks,
> Fredrik
More info on this problem and a potential workaround (not ideal, but
we've been living with it) can be found here:
http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html
http://lists.freebsd.org/pipermail/freebsd-arm/2012-February/003296.html
- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1337024264.1503.73.camel>