lkml.org 
[lkml]   [2008]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH -v6 0/2] Fixing the issue with memory-mapped file times
From
Date
> 2008/1/18, Miklos Szeredi <miklos@szeredi.hu>:
> > > 4. Performance test was done using the program available from the
> > > following link:
> > >
> > > http://bugzilla.kernel.org/attachment.cgi?id=14493
> > >
> > > Result: the impact of the changes was negligible for files of a few
> > > hundred megabytes.
> >
> > Could you also test with ext4 and post some numbers? Afaik, ext4 uses
> > nanosecond timestamps, so the time updating code would be exercised
> > more during the page faults.
> >
> > What about performance impact on msync(MS_ASYNC)? Could you please do
> > some measurment of that as well?
>
> Did a quick test on an ext4 partition. This is how it looks like:

Thanks for running these tests.

I was more interested in the slowdown on ext4 (checked with the above
mentioned program). Can you do such a test as well, and post
resulting times with and without the patch?

> Table 1. Reference platforms.
>
> ------------------------------------------------------------
> | | HP-UX/PA-RISC | HP-UX/Itanium | FreeBSD |
> ------------------------------------------------------------
> | First run | 263405 usec | 202283 usec | 90 SECONDS |
> ------------------------------------------------------------
> | Second run | 262253 usec | 172837 usec | 90 SECONDS |
> ------------------------------------------------------------
> | Third run | 238465 usec | 238465 usec | 90 SECONDS |
> ------------------------------------------------------------
>
> It looks like FreeBSD is a clear outsider here. Note that FreeBSD
> showed an almost liner depencence of the time spent in the
> msync(MS_ASYNC) call on the file size.
>
> Table 2. The Qemu system. File size is 512M.
>
> ---------------------------------------------------
> | | Before the patch | After the patch |
> ---------------------------------------------------
> | First run | 35 usec | 5852 usec |
> ---------------------------------------------------
> | Second run | 35 usec | 4444 usec |
> ---------------------------------------------------
> | Third run | 35 usec | 6330 usec |
> ---------------------------------------------------

Interesting.

Thanks,
Miklos


\
 
 \ /
  Last update: 2008-01-19 11:49    [W:0.082 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site