Re: Improve lseek scalability v3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Friday, September 16, 2011 01:06:46 AM Andi Kleen wrote:
> v3: No changes, except rebase. All reviews passed. Just reposting
> for merging.
Is anything/anyone still objecting to this patchset?

I just retested it ontop of v3.1-rc8 minus the btrfs parts (which don't apply 
cleanly anymore because a modified version of 1/7 was merged) and it works 
fine for some hours of fs heavy db using benchmarking/development.

Following is a seemingly trivial forward-port of 7/7. But since I have 
about no clue in fs development and even less about brfts - which I never used -
take it with a grain of salt.
It seems a bit ugly to have the mutex_unlock at three places btw. A 2nd patch
fixes that, no idea whether its worth the churn.
Both are compile tested only.

Even at this (2 x E5520 (4 cores)) machine there seems to be a benefit of 
about 1.5%. Not enough cores to get into the actually problematic performance 
areas as presented by Robert though.
The variance between runs is a bit too high to call it reliable though.

Thanks,

Andres


PS: I have no clue what to do with the s-o-b and changelog when forward 
porting a patch... So I just copied the original message - which seems wrong.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux