[Ocfs2-devel] [patch 09/11] ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_END

From: Jensen <shencanquan@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 09/11] ocfs2: llseek requires ocfs2 inode lock for the file in SEEK_END
Date: Tue, 11 Feb 2014 11:35:18 +0800	[thread overview]
Message-ID: <52F99A76.1090103@huawei.com> (raw)
In-Reply-To: <20140210155701.7b1bacb165ca4f89ef46b5ef@linux-foundation.org>

On 2014/2/11 7:57, Andrew Morton wrote:
> On Mon, 10 Feb 2014 16:51:32 +0800 Jensen <shencanquan@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() ;)
>
> .
   because lseek only lock in SEEK_END.  so your above mention can't test.

>