[Ocfs2-devel] [patch 09/11] ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_END
Andrew Morton
akpm at linux-foundation.org
Mon Feb 10 15:57:01 PST 2014
On Mon, 10 Feb 2014 16:51:32 +0800 Jensen <shencanquan at huawei.com> wrote:
> >> ocfs2 is a cluster file system. as like read/write/open/rmdir/unlink interface which think of cluster-aware. I think the seek interface need
> >> cluster-aware. May be it has the performance impact. but it's correctness is more important than performance.
> > That doesn't mean we can't or shouldn't quantify the performance impact of your patch.
> >
> > Please help us measure what the end-user impact of this change will be.
> > --Mark
> test result: 1000000 times lseek call;
> index lseek with inode lock (unit:us) lseek without inode lock (unit:us)
> 1 1168162 555383
> 2 1168011 549504
> 3 1170538 549396
> 4 1170375 551685
> 5 1170444 556719
> 6 1174364 555307
> 7 1163294 551552
> 8 1170080 549350
> 9 1162464 553700
> 10 1165441 552594
>
> avg 1168317 552519
>
> avg with lock - avg without lock = 615798
> (avg with lock - avg without lock)/1000000=0.615798 us
hm, what does that actually mean. I guess that to get a feel for the
impact on real workloads, this latency needs to be compared with the
time for a small IO on fast hardware.
One could test that by creating a large file then doing lots of
"lseek(random)+read" operations. Which requires forgetting about
the existence of pread() ;)
More information about the Ocfs2-devel
mailing list